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• «深入浅出面向对象分析与设计》 
对 OOA&D 这个主题的探讨令人耳 
目一新。本书与众不同之处在于它 
将焦点攉在学习上，本书的诸位作 
者让从业人员对 OOA&D 的内涵不 
再感到遥不可及.而且它在实际工 
作中*实有用 





你是否早已对市面上那些只有在成为专家以后读起来才有*觉的 OOA&D 书 
»感到厌 ffi? 你可能早躭听说过 OOA&D 书鳍能 W 助你写出伟大的软件—— 
让老板高兴.客户满*的软件. 

但如何办到呢？ 


«深人浅出面向对象分析与设计》将告诉你如何分析.设计以 及檟写 真正面 
向对象的 软件： 容 S* 用.好维护、可扩展的 软件， 不再使你心碎的软件，让 
你增添新功能而不会破坏旧机制的软件。在本书中，你将 学到： 

• 使用诸如封装 (encapsulation) 与委派 (delegation) 之类的 OO 原則建立 
灵活的应用 程序。 


■•隐匿在诙谐图片与逗趣文字背后的 
是对 OOA&D 这个主題认真.睿智 
且极具匠心的阐述 = 阅读本书，感 
觉就像站在专家的肩膀上环顾四方. 
聆听他一步步.细心倾诉那些重要 


使用开闭原則 (Open-Closed Principle) 与单一职责原則 (Single- 
Responsibility Principle) 提升程序的重用性。 

学习 如何将 00原則.设计模式及各种开发方法通通整合•到 OOA&D 项目 
的生命周期里。 

运用 UML, 用例及用例图来确保所有利害关系人都能清楚地进行沟通， 
协助你交付正确的软件，达到毎个人的要求. 


的#题.并且告诉我为什么。” 

- Edward Scion 

波士頓学院计算机科学系 剿教授 


“剛读完这本书.我就深深地爱上它 
了！我最軎欢 的一件 事就是本书把 
焦点放在我们实践 OOA&D 的原因 
上——写出伟大的软件！ _ 
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www.oreilly.com 


O'Reilly Media. Inc. 投权东南大学出版社出版 



通过一连串的®力开发，《深入浅出面向对象分析与设 
计》 压缩了学习与获取复杂信息所需的时间。可以预 
料，这将是一段充满乐趣的学习之旅.相信在读完本 
书之时,你肯定能够写出伟大的软件. 
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对本书的赞誉 


«深人浅出面向对象分析与 设计》 对 OOA&D 这个|彳理的探讨令人耳目 .新。 it 这本书与众不 
的屯要因索在于它将焦点放在学 习上， 市面 上有太 多关于这个主埋的书》,它们花费许多时 
间告诉你•为什么’，但邯无法让从业人 W 能够真正运用在项 H 上， 尽莳那呰 .|5»宂满钾 路的火 
1 花，却+能符合实务所需。我深信软件工程的未来必然聚焦 ft 从业人 K 身上，而本书的作*们 U： 
foOA&D 的内涵对从业人员來说不再遥不可及并 ft 在实务中确实有用。” 

- Ivar Jacobson , Ivar Jacobson 顾问公司 

p 我刚读完这本书，并深深爱上了它！本书设法以 UML 与用例厘洁 OOA&D 的要点，使读者能够 
[ 充分理解其中的精髓.甚至对好的软件设计也有楮辟的说明，全都是以节奏紧凑的步调，易干理 
I..解的方式进行。 我最痉 欢的一点就是本书把焦点放在我们为什么要实现 OOA&D ——写出美妙的软 
件！通过定义何谓伟大的软件以及显示 OOA&D 的毎个步®,引领读者实现那个目标，本书甚至 
让 最疲港 +堪的 Java 程序员明白为什么 OOA&D 确实很重要。对于 Java 新手，甚至对已经在业 
界工作了一段时间 . 何饱受 -* OOA&D ‘巨作’惊吓的 Java 程序员而言，这是绝佳的‘第•本 
书 • 。 ■ 

Kyle Brown ,旧 M 杰出工程师 (Distinguished Engineer) 

•■终 于， •本 OOA&D 的 4f 书面世了，它认清 UMUlft 辅助 工具，开发软件的首耍任务是花时间把 
‘各个议理 ff 细想洁绝。” 

- Peter McBreen , 《Software Craftmanship》 的作者 

& 本书延续 ‘Head First’ 系列的风格，对充满娱乐及视觉导向的效果掌握得非常好。然而，隐《 

I在決谐围片与有趣文字背后的，是对 OOA&D 这个主趙严肃. 睿智 a 精心的阐述。本书对如何设 
&计程序及有效沟通提出了强有力的观点。我喜欢它使用连续性范例的方式，引导读者体验设计流 
程的不同阶段。阅读本书时，感觉就像站在专家设计者的 fl 膀上环顾四方，聆听着他向我 -- 步步. 
f 细心解释肴恥些重要的议题并告诉我为什么。” 

—— Edward Sciore, 波士顿学院计算机科学系副教授 


-这是 .本 W 心陈述的 4f|S. 它实观了所冇对读者的承诺：如何分析、设II•以及编写真正面向对象 
的软件.本1?的内容运用用例， 行云 流水般地捕获 谲求. 以分析.设计，实现.测试并 IL 反复进 
行.面向紂象软件 开发的 毎..个步骤邯 被免现 在健仝的软件 T- 程原则之下，书中的范例£坫消晰 
且具冇说明性•这址•本关子 面向对 象软件开发的 &WR 今人耳自.新的 4f_|5„ ” 

Dung Zung Nguyen. 赖斯大学讲师 


作家们对其他 Head First 书籍的赞眚 


“结 slif 办公室甩•天10小时的程序编写工作， M 到 家后， 谁会行梢力再去探索新兴技术的 M 
-I 1 •新方面？假如开发者耍将 W 暇时间投注在白我鞭策的职收发 展上， 难道小_应该至少“一点 
»味性吗？从 O’Reilly 的新15《深入浅出 Ajax» 来枒，答案班竹定的 • 《深人浅出 Ajax »垃进 
入 Ajax Web 应用程序世界的跳板， IS 中处处充满乐《!,值得你投注时 M 与金钱 . ” 

一 Barry Hawkins, Slashdot.com 

••从简单的 tt 念与范例开始，本书小心地引领若读者从简单的起点开始，•直到读者对建立 Ajax 网 
站感到得心应手（本书结束之 时）。 本书可能是以 Web 设计者为中心的最好的•本 Ajax 书除。- 
- Stefan Mischook, KillersRes.com 

•运用 'Head First' . ‘Head Rush’ 系列惯有的诙谐逗趣 W 格，这本朽单刀直入.教你如何编写传 
送请求给服务器以及在返回时更新 MM 的相关 JavaScripi. 本书最大的好处（除了对程序代码如何 
运作的绝妙解 杼外） 足顾及了安全防护的议題。假如你通过这本书学习 Ajax, 不太可能会忘记你 
所学过的一切，- 

- Stephen Chapman. JavaScript.About.com 

•如*你想略过夸大不实的内容，直接学习如何 U;Web 应用程 ；T •使人 IfB. ■新，《深人浅出 AjaxJ 
&你不应该错过的 本书 。” 

- Kristin Stromberg, Aguirre International 

“假如你知道一些 HTML, CSS. JavaScript 以及一点点 PHP, 但你不明白这股 Ajax M ■潮是怎 
么一回事，这本书就是为你量身订做的.你将经历-段学习 Ajax 的旋风之旅，在你致达本书 
终点之前，所有你以往不能融会贯通的 Web 技术全部会整合在一起，深植你心。 tf 时，你将拥 
有 Ajax 的奇幻《力！你将明白网络上最热门的 Web 应用程序背后所隐藏的秘密，你将拥有关于 
交互式 地图及 Web 表单如何工作的知识，这会给你的朋友与同事留下深刻的印象•” 

-Elisabeth Freeman. 华特迪士尼互联网集团技术总监 

“如*你认为 Ajax 垃相杂的技术，这本书躭是为你而 写的。《深 入浅出 Ajax > lh 每- 
个 Web 程序员邯能体验到无与伦比的动态感和吸引力•” 

- Jess James Garrett, Adaptive Path 

“这本 :!S 简盘是 《 袋的糖果，我欲罢不能•” 

- Pauline McNamara. 新兴技术与教育中心，瑞士弗里堡大学 



对其他 Head First 书籍的赞眚 

••我衷心#欢《«人浅出 HTML 与 CSS, XHTML» 这本拎.它教导你黹要学习的-切，以•埋味榷 
生’的形式 ，- 

— Sally Applin, UI 设计师与精致艺术工作者. sally.com 

“我老婆倫 f 这+书，她从未从事过 Web 设计，闪此; S 要.本像 《深 入浅出 HTML 与 CSS. 
XHTMLS 这样的朽带领她从久•走到尾。现在，地已经有了一个想要逮立的网站列表——为我们儿 
子的功课，我们的家庭……运气好的话，当地完成时，我会拿回我的书。” 

- David Kaminsky. 旧 M 杰出发明人 (Master Inventor) 

“Freeman 所著的《深人浅出 HTML 与 CSS. XHTML» 对学习如何建 k 伟大网页来说是最风娱乐性 
的一本好书。它不仅涵盖了关于 HTML. CSS 与 XHTML 所要知道的毎件亊， 吏以 卓越的方式运 
用外行人能理解的词语，丰富的范例来解释所有的一切。我发现本书的阅读让人有如沐春 风的感 
觉.我真的学到了一些新东西。” 

Newton Lee, ACM Computer in Entertainment (acmcie.org) 主编 

•来 Tl «K 入浅出 Java » 的间一系列,这本书运用-切有用的技巧帮助你理解并记忆，不只是大最 
的 ffl 片.£垃人性化的图片，这.切生动有趣的说明必然能激发人们的兴趣。本书处处惊奇.抄 
笔生花，文中史足穿插广.些故事，因为人们喜 欢有® 的故事。此外，我只能说这本朽真蛙‘有 
趣得要命’ . ” 

- Bill Camarda , READ ONLY 

“这本书条理 分明. 幽默 Ml •趣、 真材实料，这使得它甚至可以帮助非程序员思考如何好好地解决问 
题。” 

- Cory Doctorow, Boing Boing 的共同编辑， 《Down and Out in the 

Magic Kingdom》 与 《Someone Comes to Town, Someone Leaves 
Town》 的作者 

“我觉 W 就刚刚把 -本千 斤万担的书举过头顶 • • 

Ward Cunningham, Wiki 的发明者. Hillside Group 的创始人 


■•我 ft 的爱 h 这本书了。亊实上，我在老婆面前糸吻7•它》 



O’Reilly Media, Inc. 介绍 

为了满足读者对网络和软件技术知识的迫切需求，世 界荇名 计算机 IS tS 出版机构 O’Reilly Media. Inc. 授权 
东南大学出版社，翻译出版一批该公司久负 B 名的英文经典技术专著。 

O'Reilly Media, Inc. 是世界上在 Unix, X, Internet 和其他开放系统图书领域具有领导地位的出版公司， 
同时也是联机出版的先锋。 


从最杨销的 «The Whole Internet User's Guide & Catalog* (被 纽约公共图书馆评为 20 世纪最重要的 50 本 
书 之一） 到 GNN (最？•的 Interne 们户和商业网 站）. 再到 WebSUe (第一个桌面 PC 的 Web 服务器软 件）， 
O'Reilly Media, Inc. -j? [处于 Internet 发展的 ® 前沿。 

许多朽店的反 》 衣明， O’Reilly Media. Inc. 是最 S 定的II•算机 RHS 出版商—— fit ISW •版#版 .- 与 
大多数计 W 机阁书出版商相比， O’Reilly Media. Inc.RftfiS 厚的I十 算机々业押 »,这使 WCTReilly Media. 
Inc. 形成 _f 一个非常不 W 于其他出版商的出版方针. O-Reilly Media, Inc. 所冇的编辑人员以前都垃程序 
员，或者 是顶尖 级的技术专*。 O’Reilly Media. Inc. 还冇许多阆定的作者群体——他们本9•珐相关领域 
的技术专家，咨询专*,而现在编写著作， O’Reilly Media, Inc. 依靠他们及时地推出 图书。 因为 O’Reilly 
Media. Inc. 紧密地与计算机业界联系着，所以 O’Reilly Media. Inc. 知道市场上真正需要什么 围书. 



仅献给想出各种办法收集龙求.分析软件.设 tl •程序的先 
知们…… 

……感谢他们想出这些好东西，可以用来产生伟大的软件， 
而且很难，以至干我们需要用这本书来解释这一切。 





作者 

Brett McLaughlin 是一名吉他演奏者，他还在与埂实搏 4—— 
- 申电沉迷于衍并 a 他 (acoustic lingers(yle) 的阪调与爵士乐.足 
忖不起的账电的 . 他换近刚刚发现的乐 ® 垃\； I? 能够 W 助别 
人成为 4f 的程汴 W. 并 aU; 自 lL 付 f!t 起账中 . 。他 对此 ® 到很快乐， 
他的套 rLeigh. 小孩 Dean 与 Robbie 也班 . 

在进入 “Head Firsl” 袖域之 lW, BrettXjNextel Communicalions 
及 Allegiance Telecom 开发企业级的 Java 应用程序 , 之后，他 
转战应用程序朦务器领域，为 Lutris Enhydra 的 Servlet 引荦 
(Servlel Engine) W EJB 容器 （EJB Comainer) 汗发内部 系统。 
这一路走来 . Brell » 迷于开放源码并 E 协助进行.-些很酷的编 
程工 ft 开发的奠基 J ； 作，像 Jakarta Turbine HiJDOM 。 他的电 T- 
邮箱是 brelt@oreilly.com 。 




Gary Pollice 将自己归类为良脾 气的老 古董，他在业 界花了 35年的时间， 
试图成 为其成 K: 过程中想要成为的人。即使他尚未成熟，在 2003 年，他还 
是殺然决然地进人学术》堂。在那里，他 •直在 摧残卜 • .代软件开发 者的心 
»• 以近乎激进的《念.如••软件是为客户开发的，学习如 何扮演 Ifl 队的- 
分子I设II•和 ffi 序的品®.优雅性及正确性都很_®*, 你蛙.个伟大的 

栉序员， 就算玷 -个序狂也无妨，” 


Gary 是伍斯特理 JI 学除 (Worcester Polytechnic Inslilute. WPI) 的实 Ul | 教授 
(Professor of Praclice. 这垃指 成力教授之前典冇实工作的经 验），他与套 
T- Vikki 以及两 Jl 抅 Aloysius ^ Ignatius 使 在马萨 Wf 寒州 中部。 你 HTUiH 他在 
WPI 的中 .IS. http://web.cs.wpi.edu/~gpollice/ 。 別其气，存关干本书 
的抱怨或鼓励 . 谪吊管留言给他。 


Dave West 想要自 B1 为一名电肭极苒 Uheikgcek) 。遗憾的足，其他人都 
不想这样描述他.他们认为他是一个专业的英 H 人，喜欢以传道土般的无 
比耐心 与热怙 谈论软件开发的最佳实践。最近， Dave 转职到 lv ar j ac0 b s0n 
Consulting。ft 昴里.他负贵美洲亊务，现在， 他可以 把与人谈论软件开发 
和推销撖甩球与足球的热情结合 起来， 并且与人辩 论板球 比榉球 E 加刺激 
的话 

在为 lvar Jacobson Consulting 负赶羌洲事务之前. Dave 为 Rational Software 
(现 LL 成为 IBM 的.邡 分） 工作过几年， Dave 在 Ralionul y IBM 祖任 过1 午 
多®! 务. tittRUP 的产品 经理， 在那 M, 他将插 (1: (process plug-ins) 
(agility> 幵发的观念带进 RUP。 你能通过 dwcsl®ivarjacobson. 
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谁适含读达本书？ 


如*对于下列问越，你的答案邯足 "Yes" 
0知 ifiJava 吗？（不必足 京） 


( g ) 想要学习.1•解， i 己住 jf- 且将面向对象分析与设计 
应用在现实世界31,并以此流程编 5 :i «£好的软件吗？ 

@喜欢刺激的晚《对话胜过枯燥乏味的学术演讲吗？ 


那这本 B 就适合你。 


淮或许应该迗离迖本书？ 

如杲对于下列的任何一个问题，你的答案是 "Yes' : 

® 你完全不会 lava? (不必是商手. 4ll*^t« Java. 
t«C# 也 《T 以，你可能 ffl 解几乎全部的范例程 
序代码,如采你只有 C++ 的背 *. 可能也没问 
独 • > 

(D 你&正在寻找参考书的了小起的 oo 设讣师 /开发 
者吗？ 

(D 你宙怕尝试不间的事物？宁可接受牙根管治疗， 
也不愿意混搭条纹与花格子布？认为将 编程概 
念拟人化的技术书籍不够认真严肃？ 


那这本书就不适合你。 


«何<5现會成1用十的人。1 




介绍 


我们知通你在想什么。 

••这 怎么可 能是一 本严肃的程序设计书»? ■ 


*a -堆 iaa 干吗的? 
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如 何使用这本书 


我们将 "Headfirst" 的谈老视为 ¥_ 空±。 

不只是页面上的文字。我们知道如何帮你的脑袋开机。 

* i * a -®**#ai 

Hea «l First 料抑 1 : '"'"T *** 

^篇近相关联酬像中， r^\ 

使用对话方式与拟人化， 

=二侣的耳娜獅 — 

刪_眺二, " w 说 _„«_娜.獻" 

^^ 二=二 二二 r «« - — 

0 mis 郝肤的紗。 广 ^ 

v,f 巧令 : 

A \，rnl m . «»• 

abstract 他 d roa f .⑽ '麟糾⑽ ㈣ .相来采必枯»乏味，如 A , 

. i( J 料觉触》，贼】 成齡賴快 财。 | H | 

生的惊 W . 好奇.為曲以及 « WH， 


»*«»». *-*1 i 
SMttUa«M 加蟪？ I 



无认釦： 兵子思、考 的思考 （想一想如何思考） 

如采你典的想学习，想学得更快.吏深入，那么请注息你蛙如何集中注意 
力.想想如 H 思考，学学如何学习。 

大多数人在成长过程中没有 lit 过元认知 （memcognition) 或学习理论的课 
程，我们希错学习，却又不知逍如何学习. 

如果你 f •里正 拿着这 本书，我们假设你想学 dOOA&D, 而且可能不想花费 
太多时间。 因为 你即将要开发软件，你必须记住读过的东西。为此目的， 

你必须理解它。想要从本书（或者任何书.学习经验）得到最多利益，就 
必须好好地照料你的大 ®, 让你的大脑好好注意这些内容。 

秘決在于让你的大《认为你正在学习的新知识确实很重要，与你的生 
死存亡有关，就像噬人的老虎一样。否则，你会不断陷入 苦战： 想要记 
住这些知识，却总是记不住， 

那么，如何让大脑将 OOA&D 视为 一只饥 饿的大老虎？ 

•ff 慢 R* 琐的方法.也有快 a 有效的方法。慢的//法躭垃多读几次。 

你很清楚，助能补拙， m 乏味的知识也能#会并 id 住， 只要® M 的次数 
够多，你的大 w 躭 会说： “&然这感觉上对 他不® ®, m 他却一而 w . w 
而•:地苦读这个部分，所以我想这应该垃艰要的吧！” 



较快的方法則适做任 H 增加大脑活动的事，特別足 类嘲 的大眙活动。 

所提到的东西是解法的一大部分，已经证实有助于大《运作，比方 
说，研究 a 示把文字放在它所描述的图片内（而不是 s 千!《面内其他地 
方，如图片说明或正文），可以帮助大脑尝试将两者关联起来，这会触发 
更 多的神经元.更多的神经元被触发就等同于让大》有更多机会将此内容 
视为值得注意的信息并且记录下来。 

对话式风格也很有帮助，因为在意识到自己身处对话中时，人们会 付出更 
多的关注，因为他们必须竖起耳朵，注意整个对话的进行，跟上双方的谈 
话内容. 神奇 的是，你的大脑根本不在乎那足你与书本之间的“对话”！ 
•方而，如*写作风格既正式又枯燥，你的夫 B 会以为正在聆听-.场演 
讲.自己只是一个被动的听众，根本不需 要保持 请《. 


然 ifti . 阳片4对话式风格只不过址•个幵端》 


►译注丨：认知， melacognilion. 教 W 心®学上的专有名 
均。管 a 学习和认知的过 《. 极高竽习的效年,. 
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如何使用这本书 


达是我们的 做法： >-2. 

我们使用 ra 片，因为你的大 w 对视觉化效果比较打感觉.而不 a 文宇。对你的大 w 来 
说.一 a) 值••千■•字 . 当文字和围片••起使用时. 我们 将文卞嵌人围片内，因为你的大 
脑在文字位千它所涉及的 in 片内时（而不是在 RI 片说明或荇埤没在正文的某处）会运作 
泔更有效串. 

我们 sa 衣现柑同的内荇，以不 m 的衣现方式、不 m 的媒介. 多艰 的感知叙述相冋的事 
物，这是为 r 增加机会，将该内容烙印在大脑的不同区域。 

我们以超甲预期的方式使用概念和 ra 片， it 你的大齣觉得新鲜有趣。我们使用图片和多 
少具有一些情感的想法，让你的大脑觉得感间穿受。让你冇感觉的事物，内然就比较容 
易被记住，即使那些感觉不外乎幽默，惊讶. 有® 等. 

我们使用拟人化.对话式的风格，因为当大 w 相倍你正处干对话中，而不是被动地聆听 
演说时会给予更多关注，即使你交谈的对象是•本书。也就适说你即使在阅读，大脑还 
是会这么做。 

我们包含了80个以上的活动，因为当你在做事悄而不是在读啦情时.大脑会学得电多， 

U1 得更多。我们 u ■.习題维持在具冇挑战性，又不会太堆的栉度.因为那足多数人所偏爱 
的情况. 

我们使 HI 多*学习 W 格. W 为你能比较《欢•步•步流 W. 佴苎人#欢先了解枏体轮 
邮.还冇些人《||«欢1*1；接序代码范例。然 rfii, 不 W 你垃哪一种人.邯能够 受敁 于本 
1«以不 M 方式衣现扣冋内容的手法。 

本书的设 tl _ N 时考虑 /" 你的左右 W . 因为越多的 W 细胞畚与，就越 " f 能学会汴记仕 . 而 
且保持史 K ： 时 ful 的专注。因为使 ) n -边的大《,往往窓味着》-•边的大脑有机会休息， 
你 fir « r 以学得更久.史有效率。 

我们也会运用故亊和 练习呈 现多个角度的看法，因为当大 W 被迫进行评估々判断时会学 
习得更深人， 

书中也冇相当多的挑战和练习，通过问问题的方式进行，答案不见得都很直接，我们的 
用意是让你的大 B 深涉其中，学得更多， id 得更牢。想想看，你无法只是看见人到健身 
房运动，就让自己 实现哦 身的效果。但是.我 (fl 尽力确保你的努力是用在正确的事情 
上_你不会庀费额外的眛力去处理难以理解的范例.或难以解析.圯满行话.咬文嚼字 
的论述. 

我们使 ffl 人物.在故事、图片与范例中，处处都 fe 人物，这是因为你也是人。你的大脑 
对人会比对亊物史加注意， 

我们采用80/20法則.我们假设， 如采 你想取 W 软件设计的 W 士学位，你不会只肴这本 
15,所以本 H 不打算包罗一切.我们只提供你实阮潘要的知 UU 



©炉夜活 



xxviii 介绍 




介绍 

让你的大胎颀从你的方法 


好吧，该做的我们都做了.剩卜_的躭靠你丫.这里介绍一些技巧，但只是一个 
幵端，你应该听从你的大 W . 哪咋对 你的大脑冇效，哪*尤效.稽 


吧！ 


i'94f4(Sj 


(D 慢慢来.理解越多. 霑要强 记的就越少。 

不要光读，要记得停下来，好好思考。当本 
15问你问題时，不要完全不思考就直接看答 
案。想象有人正面对面问你这个问题，如果 
能够迫使你的大脑思考得更深人，你就有机 
会学会并且记得 吏多的 知识。 

(D 勘做练习.写下心得。 

我们在书中安排如*你光看不做. 
躭 W«t A 垃苻别人 在站 9■玢运动 1*1 己却不动 
■tf. 那坫不会冇效*的.使用铅笔作答。大 
ttiiElKSl 示，学习中的实 W 活动会 提布学 的 
效! ft - 

(D 认真阅读"常问的问题"单元。 

洋细 W 读所冇的“常问的 H 题”。这可不是无 
关紧要的说明.而是核心内容的一部分，千万 
别略过！ 

® 将阅读本书作为睡前最后一件事，或者至少 
当作睡前最后一件具有挑战性的事。 

学习的一部分反应发生在放下书本之后，特别 
是把知 UI 转化为长期记忆的过程更是如此。你 
的人 - W 需要 fill 的时间进行更多的处理。如采 
你在此处理期间塞进新知 W , 某些刚学过的东 
两将会被遗漏。 

® 喝水.多喝水。 

你的大 W 龙要 a 泡在宂沛的液体内才能运作 ft 
好，脱水（往往发生在感觉 L . I 渴 之前） 会减缓 
认知功能。 


(6) 谈论它.大声谈论它。 

说话驱动大脑的不同部位，如果你需要理解某项 
事物或者加强记忆，就大声说出来。大声解释给 
別人听，效果 更佳。 你会学得更快，甚至触发许 
多新想法，这是光凭阅读做不到的。 

® 倾听大脑的声 音，， 

注意你 的大瞄 是否超负荷，如果你发现自己开始 
漫不经心或者过 B 即忘.就应该休息 T . 当你错 
过某些重点时，放慢脚步，否則你会失去 E 多。 

® 用心感受！ 

必须 U : 人脑知道这 一 wflim ® 要，你 - r 以让自己 
融人故 亊电， 为照片加上你 fid 的说明，即使抱 
怨笑话太不好笑，都比奄;觉好，任何®觉对 
学习效果都有帮助。 

(D 设计某些东西！ 

把所学应用到你正在设计的某件新亊物中或東做 
旧项目。反正就是尽 鼉运用 知识，获取本书习题 
与活动之外的实践经验。你所_要的是-个要解 
决的难哩，试着运用我们所谈到的技术解决它. 
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如何 


淡我 

这是 -段学习经验， ifiM 〈是•本参考书 • 所有 HIK} 学习的东两，我们邯会刻息徘除。第.次阅读时你 
必须从头开始， H 为本 1S 对读者的知识背 S 做 C •咋假设. 


我们假设你熟悉 Java。 

教你学会 Java 可能得花一本书的篇幅（事实上， 有… 本好朽正是为了做这 件事： 《深人浅出 
Java* ) ,我们选择把这本书的焦点放在分析与设计上，因此章节的编写是假设你丫解 荩础的 Java. 然 
而，当中级或高级的编程概念出现时我们会仔细说明，就像那些概念对你 rfii 言是全新的体验一样。 

假如你对 Java 全然陌生，或者是以 C# 或 C++ 的背詨为基础来阅读这本书，强烈建议在你继续阅读之 
前先拥阅本朽后面的附录2。该附录介绍了-•些必要的材料，让你踏出正确的第一步。 


只在必要时才使用 Java 5。 

Java 5.0 引进 J* 许多 Java 语言的新功能，从泛® (generics) ,参数化类型 （parameterized type). 枚 
举类 (enumerated type) , 到 foreach 站坏构造 （conslrucl) • 1午多々业的程序员正往 Java 5曲进， 
何我们不想 it 你 在试特 学>] OOA&D 时还被耽搁 ft 新的语法多数情况 T, 我们尽可能使用 Java 5先 
前的语法，唯•的例外垃第I敢，在我们黹要用到枚堆类呦时，我们会以某种作细 fil 度解 W 枚举 
(enum). 

即使你是 Java5 新乎，对任何程序代码范例也应该没有什么闲难，你会得到•些 编译器 关于未 
检査 （unchecked) 与非安全操作 （unsafe operations) 的警告，那是因为我们缺乏类型化集合 
(typed collection) ,假如你已经熟悉 Java 5,应该能轻 S 地以 Java 5的方式更新它。 

不要略过任何活动。 

练习与活动并非附加的装饰品，而是本书核心内容的一部分，有些可以帮助记忆，有些可以帮助理 
解，还有些可以帮助 应用。 所以，请不要略过这些 练习。 填卞游戏足唯.-非必要的部分，佴是它们可 
以帮助大 脉在不 N 情境下回顾-下学过的字词与术语，对干这部分，中文版将保留原文，方便读者玩 
此 游戏， 
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重复是刻意且必要的。 


我们希望 "Head First” 系列能让你真正学到东西，希望你读完此书后能够 id 住所读过的内容.大部分 
参考 用书并不将此当作一个目标 • 本书的重点放在学习上，所以某些重要的内容会…再出现，加深你 
的印象。 


程序范例尽霣精简。 

我们的读者告诉我们，不希锘苻到书中列出200行的程序代码，而当中和上题有关 的又键 程序代 码却只 
有两行。本书尽 ft 把程序代码缩短，让学>1的过程渚晰简申.。不耍期待所有的程序代码都很牢 辐或完 
毕® 我们 的程序代码是作为辅助学习之用.不见得一定是功能完 tt 的。 

在某哼例子甩，我们并未把所冇需®的 import i/HoWfeift 进来。然而，如采你垃 Java 程汴61,你应该 
toifi Arr.yList j.va.util to!ftigimport^« f J2SE API, 我们会特別说明.所有程汴代 

Pi 部已经放在网络 h, 可供下栽，网址是 http://www.headHrstlab3.com/books/hfoo/ 1 . 

另外， 为了把热点放在程序代码的学习上，我们并末-在书中把*放进包中（换句话说，所冇类邯垃位 
认包里> ^不途议你在真实的项031也这么做。 

“动动脑”习题没有答案。 

对某些人来说，这类习题没有一定的答案，对其他人来说， ••动 动脑"习题所启发的学习经验在于让 
你决定你的答案是否正确以及何时正确。在某些练习中，我们会提供暗示，给你指引正确的方向。 





技术审 阅者: 


«心 达谢 我们惊人的技术帘阅•:人组，这几个家伙逮 到我们 所犯的错误，控制我们的节 
if . tf 至 it 我们知迫我们的笑话太不好笑.冇 4 f 几次，他们来来间间几个章节好儿个小 
时……不确定他们是否真的有帮助,成者该*软件开发远•点 s Hannibal 在他告诉我 
们第 10® 的 OOA&D 人箭头很棒时，特別放我们•个扎拜的假。谢啦，你们这些*伙， 
没有你们的锲而不舍.这本书就不会那么的坚实稳间. 


Kathy Sierra 与 Bert Bates : 

Bert Bates 对悬崖以及 Kathy Sierra 对狗 N 的 
专业性与润察力 - S 让我们为之惊叹。假如这听 
起来不太合理，別惊讶——当你遇到这两个人时， 
几乎所有你知道的事邯有 f 新观点。然而，我们 
还是走过来了，由于他们的帮助，••切变得更美 
好. 
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收鑲索求 

给客户所需之物 

每个人都想让客户满意。 你已经知逍 编〜 Jfli 人软件的第•个步保它 
完成客户要它做的事。 m 足如 Hffl 解客户 真正要 什么？如 w 确认容户真的知追他 
们®什么？这 M 就蛙良好志求的糖力点 • 在本茕，你会学 习到如 H 确保你所交付 
的东西确实符合客户的真正需求， it 你的客户满意。在你完成之时，你的项目将 
是“保 ill •:满意”.并 R 你也将步上编写伟大软件的永饵之进。 


大显身 手的机会来了 56 

澜试驱动 59 

不正确的使用 （存-点） 61 

那么.需求究毚是什么？ 62 

创垅耑 求列表 64 


ToiMAWmMW 门. K 本 2. 0 | 

一‘ 纛求刊來 

1,5 — SHLAMBt*iSn^!6*lo 

2.遞 Wn«*tV 

孖齲 LFUo 在叫_ 出去。 

2 _To*i«WMa»ft«FW 0 在叫。 

3 ~ 

"-♦鸚 n 打开。 

SFIdoffiifc*。 

6.FM0 办它的專。 

——/Fido©#. 进门。 

蓽.箱门6动兵闭。 


为锘误 作规划 

»代路袷 (altcmale path) 处理系 统的貼难问埋 

(再 次)介绍用例 

一个用例. ：( 个部分 

按照 HI 例检査黹求 

你的系统必须在真实世界里运作 

认识快乐路径 (Happy Path) 

OOA&D I:具箱 





«4 J 铉 的一砟 
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溧求变更 

A 山可移，此情永不渝……现在，情况有变 

^ 你认为你已经掌握到客户想要的东西了吗？先别急 ……想必你已经 

和客户 W 论过，收 *4f 需求， 也写了 出你的用例， 并且已 经交付 f 很好的应用程 
序。现在该是轻松…下.来杯鸡尾酒庆祝庆祝的时候了，是吧？足啊……直到客 
户决定告诉你，他们真正想要的东西与之前跟你讲的不一样。他们爱你所做的- 
切，真的,•但现在那个已经不够好。在真实世界里，需求总是时刻在变，而月.解 
决这些改变且让客户满意就全犇你了。 


你是英雄！ 112 

牺牲品？ 113 

软件分析与设计的不变真理 115 

可选路径？替换路径？谁能分得清？ 120 

用例对你而言必须合理 122 

从开始角完成：绝 •场& 124 

袢换 路袷的 K 心话 126 

完成潘求列表 130 

SU 程序代码，逊！ 138 

最后的测试驱动 140 

写下你自己的设计原则 141 

OOA&D 工良箱 142 







目录 


4 


分析 

将你的软件带进真实世界 

是逐步发展成真实世界的应用程序的时候了。 你的应用裎序能 X; 

起门来，只在自*的开发 坏境里 运作.细致地调整以及完美地安装，而你的应用裎 
序必须服务离实的 人们。 本章完全关系到确保你的软件能运作在真实世界的怙境屮 
(context ) 。你会学文本分析 （textual analysis) 如何把你一直忙于的用例转换 
成客户所要的类与方法.当你完成时，你可以大 声说： “我办到了！我的软件已 
经准备好面对真实的世界了！ ” 







(第 一部） 


(插曲) 


良好的设计=炅活的软件 

诸行无常 

改变不可避免。 无论你现 ft 有多喜爱你的软件，它很可能明 K 即将改 
变。你的软件越难改变.就越难响 ft * 户需求的变史.在本软，我们将 t 新 
拜访一位老朋友，试 e 改#他现有的软件项目汴且肴肴小变|£如 h 变成大问 
题。亊实上，我们将发现问哩的确很人，以至子我们必须采取两部分的章节 
来解决。 


Rick 的吉他事业 .4^ 叛日上 
抽象类 

类图解析（再 一次） 


198 

201 

206 


UML 小抄 


207 


设II•问 题的* 告 213 

通往伟大软件的 : .'m (Si*) 215 


oo 大取 n! 


对象村最受欢迎的机智问答秀 
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(第二部） 


良好的设计=灵活的软件 

给你的软件30分钟的伸展操 

你曾经希望你的软件再多一点点灵活性吗？ '*1 你遇到变史应用稈序 

的问題时,很可能意味着你的 软件需 要更有灵活性 (flexible). 史:具 复原力 
(resilient). 为了帑 助你扩展应用程序，你将要做一些分析，一堆设 计并且 
学习 OO 原則如 W 降低应用程序的 網合度 （coupling) 。最后，你屙到 较商的 
内聚力 (cohesion) 如何帮你降低耦合度。听起来有趣吗？拥到下一页，让 
我们回头修改那个不具灵活性的应用程序。 


回到 Rick 的捜索工具 234 

仔细瞧瞧 searchO 方法 237 

分折的好处 238 

类实际上关系到行为 241 

设计之死（决 策） 246 

将坏的设计决策转变成好的 247 

Rick 的软件中的“双封装” 249 

不要宙怕犯错及改变 255 

瞧！ Rick 的具有灵活性的应用程序 258 

测试驱动 Rick 的设计良好的软件 261 

改变 Rick 的软件有多容易？ 265 

变更容易性的大挑战 266 

具有内聚性的类善于处理好单一亊情 269 

设计/内聚力生命周期 272 

伟大的软件通常就是“够好的软件” 274 

OOA&D 工具箱 276 



解决大问越 


“我的名字是 Art Vandelay ……我是架构 
师” 

真正做大事的时候到了，准备好了吗？ 在你的 OOA&D _1:具筘电11 
经有了许多1具，但是当你必须真 lE 做大事时，你知适如何使用这些工具吗？ 
好，你吋能不了解，但你确实已经具备处理大问哩所需要的毎样东西。我们即 
将学到一些新工具，像领域分析以及用例图，然而这些新工具都是基干你已经 
知道的車，如聆听客户以及动手写程序之前了解你将要构建什么。准备……开 
始扮演架构师的时候到了。 



大问 ■ 


解决大问题 

•K- 键在于你如 H 看待大问题 
耑求与用例是个好起点…… 

共同性与变化性 
整 理功能 

功能弓黹求之间的 •'盖 別” 

JH 例不总垃 帑你# 出 锒体轮 廊 

用例图 

小小参与者 

参与者也是人（好吧，不 全然） 

做一点领域分析吧 
化整为笨，个个击破 
別忘了真正的客户是谁 
何谓设计模式？ 

OOA&D 的威力（以及一些小常识） 
OOA&D 工具箱 


280 

281 

286 

287 

290 

292 

294 

296 

301 

302 
307 
309 
313 
315 
318 
320 
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架构 


为混乱带来秩序 

你必须从某处开始，但最好挑个对的地方！ 你知道 4 iiW 把 你的应 用 稅汴 
分解成I午多小问题，俏这代表你有I午多小问题。在本® E, 我们将 W 助你想出从 
哪电着手，并 IL 确保你+会把时 M 浪费在错误的事情上 • 现在是 it 我们把工作空 
间里1«)处乱放的所有小片段整理整现，泮且找出如何将它们转换成有31织， 设计 
良好的应用程序的时候了。整隹下来，你会学习到重要的架构三问 (3 Qs of archi¬ 
tecture) 以及风险这个重要的议题。 



感觉有点头昏吗？ 

我们需要架构 
从功能开始 
什么是架构的意义？ 

架构三问 
减少风险 

场扶釘助于«少风险 
一次把焦点放在-•个功能上 
架构是你的设 It 结构 
再访共同性 

共 N 性 分析： 通往灵活软件之路 
什么意思？问客户吧。 

减少风险有助于伟大软件的编写 
要点 


324 

326 

329 

331 

332 
338 
341 
349 
351 


361 

366 

371 

372 
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设 i 十原则 

原创性被高估 

模拟是避免做傻事的最佳方式。 没冇琪情比闲扰你数 II 的唯 B 被想出令新 
且具有原创性的解法史令人振奋一直到你发现早在你之 A 9 躭已经有人解 决过冏 
样的问题.甚至做得比你好。在本章里，我们会#宥•叫人们已经想出好些年的 
设 H ■原则，以及它们如 H 帮助你成为•个好的设 _ W •者。先把按照你0己的方式做 
的想法放一旁，这-章是关干以更好.更快的方式做。 



设 I 十原則大集合 
开关原 W ( OCP ) 

OCP , -步一步来 
不自我* 复原則 （ DRY ) 

DRY 完全关系到一个地方一个潘求 
单 -职# 應則 ( SRP ) 

找出多撤职改 
从多® 职*到电一职* 

Liskov 替換原則 ( LSP ) 

子类化的误用：误用继承的案例岍究 
LSP 揭雜继承结构 所隐藏 的问题 



子类型必须能#换其基奘型 

违反 LSP 造成令人困惑的程序代码 

将功能性委托给其他类 

使用组合将来自其他多个类的行为集合起来 

聚合•：组合，但没有突然的结束 

组合 vs . 聚合 

继承只是选项之一 

要点 

OOA & D 工具箱 
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377 
379 
382 
384 
390 
392 
395 

400 

401 

402 

403 

404 
406 
408 


414 

417 

418 
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送代乌测试 

软件终究是为客户服务 

是让客户知道你真的很在乎他的时 候了。 唠叨的老板？忧心的*户？相 

关人员•天到晚在问 ••会 准时完成吗？”设计 ft 好的程序+足以取悦你的客户> 
你必须 it 他们看见某咚«正在运作的东两。既然你已经有了坚实 iaia 的 oo 编 w 
工具组，现在正是学习如何向客户证明你的软件确实 "r 行的时候.在我 
们学习到两种深入软件功能的方法，在客户的心坎上带来一股暧流，让他 们说： 
是的，你确实是栴任这项工怍的最佳人选！ 



你的工具箱满了 
伟大软件的编写是迭代进行的 
电深入地 迭代： 两种基本选择 
功能驱动开发 
用例驱动开发 
两种开发方式 
功能分析 
编'弓测试场饮 
测试职动开发 
再探共同性 
强明共间性 
强调封装 

比对你的测试与设计 
澜试案例解析…… 

向客户证明 

到目前为止.我们一直在按契约编程 
按契约编程关乎信任 
防御性编程 

将你的应用程序分解成较小的功能块 
要点 

OOA&D r.Jt® 


xix 
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00 A 邡生命阖期 

组合在一起 

准备好了吗？ 我们 s 在运用各种方法改辫你的软件，而现在该垃时 
候把 --ia 组合起来了 • 这就垃你 .it 在等待的 事情： 我们即将运用你- 
直在学习的毎一件亊，炸 it 让你看到这些真的全都是伟大软件编写浼程 
的一部分一-次又一次地编写出伟大软件。 


开发软件， OOA&D 风格 484 

对象村旅游 488 

对象村地铁线路图 490 

功能列表 493 

用例反映使用性，功能反映功能性 499 

现在开始迭代 503 

仔细#看地铁的表示 505 

使用或不使用 Line 类……那是个 M 题 514 

对地铁的乂 •注要 点 (SubwayJS) 520 

保护你的类 （还 冇客户 的类） 523 

屮场休息 531 

回时黹求阶段…… 533 

聚焦于 程序代然后 S 焦于客户 535 

迭代 （iteration) ij： 问埋比较容易 539 

路线看起来像什么？ 544 

让自己看看对象村！ 548 

第_•:次迭代，有人要试试吗？ 551 

旅程末结束…… 555 



XX 
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附录1:本书遗珠 

前十大主题（本书未涵盖到的） 

信不信由你，还有很多东西要探究的。 适的.即使已经阅读 

了超过550敢， 还是存 咋事情没被涵盖到。 即使 »后这10个题只垃 
稍皤 提- 下，我们还垃想让你在离开对象村之前，对这些上理拥冇多 
-点的信息 • 但是，嘿嘿，在 “OO 大灾难！”节 B 的广告期 M, 你 
还有一些亊要谈……谁不喜欢时不时就来点刺激的 OOA&D 谈话？ 


R 设计 •式 

«« " h « - 4 續糾 1 & I 

ftftttKWW 出* 托 I 


#1. IS-A 与 HAS-A 
*2 . 用例格式 
«. 反设 il •模式 
#4. CRC 卡 
•5 . 度量 
*6 . 顯序图 
#7. 状态围 
#8. 中.元澜 W 

#9. 编码 fc 准弓町读的程; r ■代码 
#10. 重构 









附彔 2: 欢迕光临对象村 

说00的语言 

准备去旅游卩巴。边拜边对象村的时候了，在那片上地上，对 ft 正在 
做它们应该做的事.佐用程序全邯 进封装 良好的 （不 久，你便会发现它 
的真正意 思）， 设计則 a 于®用及扩展。然而，出发之前.有些事情得 
先让你知道，有些语言技术你必须先学习。不过别担心，用不了多久你 
便会理解，你将会说 oo 的语言，就像你已经在对象村的设计良好区域 
( well-designed area ) 里生活了许多年。 


UML 与类图 577 

接下 来是： 继承 579 

还有多态…… 581 

最后 W 不垃®+ 8 要的： 封装 582 

要点 586 


(((•« «•*•**) 8 5 1 * 
象垮中*的 1 * 


坊. *4 

fif 

*»«#«. 
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良好应用程序的 i 石 


伟大软件由此开始 



那么，如何真正写出伟大软件 (greatsoftware) ?试图想 

出从何着手从来就不是_ -件容易 的亊。 应用程序真的尽了它的本分了 
吗？像程序代码重复之类的事又如何呢一这不会是一件好亊吧？通 
常很难知道应该先做什么，还得确保+会把流程里的其他事情弄糟。 
不过别担心，读完本审:后，你将知道如何写出伟大的软件，并且走上 
改® 应用程序开发方式的永 M 之道，級后，你将明白为何 OOA&D 垃 
ik 你的人生多姿多彩的4个卞母。 




永迗的摇滾乐！ 

没冇东两比得上从伟大演#者手中那把完美占他所流泻出的天®。 
Rick 的吉他店专为眼光敏说，品味出众的客户#找完»的 吉他。 



就在几个月 m. Rick 决定扔掉以纸本操作为基础的占他记录系 
统，开始使用以电 W 操作为某础的系统管理他的库存。他委托 
•家名为 “Down & Dirty 编程”的软件公 ill 建立库存管理应用程 
序， 其至 请该公司为他逮*新的搜索X具，帮忙为客户与他们心 
中的梦幻吉他配对。 


良好应用程序的基石 


Rlek 的金光闪闪的新 SfflS 序…… 

这是 -Down & Dirty 编程 • 公司为 Rick 建立的应用程序……他们 
让了一个系统，完全取代了 Rick 的旧的手巧数据，并 RW 助配对 
客户与他们心中的梦幻 W 他，下面& 他们给 Rick 的 UML 类 ifl, 冉 
诉 Rick 他们败了什么 好事： 

a ( cu «<) 的*僻 （ iMW " c *) 

象象5：。 ~~^ 


W 总的獱索垂的 的方: .在 


此濟鰱 0 期 g 供货的 


这轚基 Quitat 

iftwi* 

( va > ittle ) „ 


ii 1 & O 
戋的方•:在 
(m«tW) 




serlalNumber: String 
price: double 
builder: String 
model: String 
type: String 
back Wood: String 
topWood: String 
getSerialNumber(): String 
getPrice(): double 
selPrice(float) 
getBuilder(): String 
getModel(): String 
getTypef): String 
getBackWood(): String 
getTopWoodf): String 


c 


guitars: List • 


addGuitar(String, double, String, String, String, 
String, String) 
getGuitar(String): Guitar 
search(Guitar): Guitar 


it * 法 戏唛吉 
他存考 . 达® 
i * 畜坫 的的象 
(o6j«0 。 


戶的物 



R 

Ai . 

b/.a 值用的本科 i 


浼来过对象村？ 


老 ftiCJMC 乌00_«新孕 
时下去之光录 
2 -我们巧«；#备了 _ 墊耔 


假如你是 OO 编栉新 T.. 没听过 UML 或者不确定上图在说什么，没关 
系！我们特別为你准备了 “欢迎光临对象 M” 大扑丸来帮助你 开始。 
W 到本书后面，阅读附录2——保 IiF. 你满息。读完后再回到这里.感 
觉会 very good 啦！ 


餘 






Rick 最初的程序代码 


迖里是 ^ uitar . java 的程序代码 

你已经在上一页看过 Rick 的应用程序的类图。现在，来® 
ff Guitar . J » v « '.j Inventory . j 應 v ■文除的程序代码. 



public class Guitar { 










良好应用程序的基石 


认及 lHventory.]ava. 

_ _ i & a . *们*專入 

public class Inventory ( (; „) 碭？ 1=( 略 W •爷省 

private List guitars; 

空用- 


public void addGuitar(String serialNumber, double price. 

String builder. String model. 

String type. String backHood, String topWood) { 

Guitar guitar = new Guitar(serialNumber, price, builder, 

model, type, backWood, topWood); 冬 〜 ⑷ 0 41 爱所 
guitars.add(guitar); - - 的薄性 W 舍 的 

public Guitar getGuitar(String serialNumber) { <«««• ® ^ 

for (Iterator i - guitars.iterator<); i.hasNexCO; ) { 廣存中， 

Guitar guitar = (Guitar)i.next(); 

if (guitar.getSerialNumberl). equals (serialNumber))( 
return guitar; 


public Guitar search (Guitar searchGuitac) I ^ 
for (Iterator i - guitars.iterator<); i.hasNextO;) 
Guitar guitar • (Guitar)i.nextO; 

// Ignore serial number since that’s unique 
// Ignore price since that's unique 
String builder - searchGuitar.getBuilderO; 
if ((builder !- null) “ (!buildec.equals(' > ")) “ 
(ibuilder.equals (guitar.getBuilderO))) 


这个方法布魚 •••••• 它賴进來 






OOA&D 少年事件簿——消失的吉他 


然 ffi , Rick 的窖户 ff 始该失…… 

不管 W 位客户，@欢哪种吉他， Rick 的新搜索程序进行 K 对时似乎总是返回空 ...... 

值.但是 Rick 知道他卉客户想要的吉他…… | ii | 埋出在哪儿？ 门. *WR,chMHi. R.ck^sf 


奋鹰绔 中獯索 


public class FindGuitarTester { 

public static void raain(String[J args) { 
// Set up Rick's guitar inventory 
Inventory inventory = new Inventory!); 
initializelnventory(inventory); 


0, "fender", "Stratocastor", 



ii 4 









良好应用程序的基石 



你 的铝？ _ 

要怎样重新设计 Rick 的应用程序？ 

吞#前闹三斑里 Rick 的应用程序的程序代码以及执行搜索后的结果。看到 
什么问题了？该怎样改？在下列空白处写下你要修改的第一件亊. 


当前位璽 ► 7 







良好应用程序的基石 



当荫位 8 ► 9 




问得好！ 有一 拖拉机不同的 答案： 


；对窖户 在善的 a 序设 i +押说： 


'•伟大软件总是做客户要它做的事。因此即使客户突发 i 
要以新方式使用软件.它还是能 © 交付客户预期的路 s 


好的00 

是 杏寻我序代 


用糾携 a ： w < ae 运 
卖的00 技; 


不 {ilSiilft 说代么崦： ;1 _ 
兵系……在后®的#赛*你 


'•伟大软件使用千*百*过的设计横式与原则。你已经让你的，^ ^ 

对象保持低網合 (loosely coupled). 让你的程序代码因禁 
止修改而关 ffl. Bit 时關开《[。：《也抑刊; 财代 Bl 
更能■复利用.因此你不必■做 毎一 件事，就可以一次又-、^ 

次地运用应用程序的部件 . ” 


“伟大软件是面向对象的程序代码。因此没有一堆讖复的程 
序代码，毎个对象将自己的行为控制得很好.扩展也很容易. 
因为你的设计既稳固又灵活 .• 










良好应用程序的基石 


U 尖你的铝 I 


你认为“伟大软件”是什么？ 

你已经看过各种类型的程序设计师对伟大软件的看法，那么 
谁是对的？或者你有自 Li 的看法？轮到你说说了，写下你认 
为是什么造躭了伟大 软件： 
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伟大软件让客户满意.也让程序设计师满意 


伟犬软件 …… 

不只是二件攀 

“伟大 软件- 的意义是什么？结论不会只是一个单纯 
的 定义。 亊实上.第10页里的毎个程序设计师全都 
说对了一部分_ 


第一，伟大软件必须让客户满意. 
做客户要它做的事。 


t 贏得客户的芳心 

当软件做好它应该做的亊时客户 
会认为它是伟大的。 


达 立把?对的软件是伟大的，那么当你要增添 
自己的东西到程序代码中，或将它®利用在其他应 
用程序中时又如何呢？只让软件完成客户交代的事 
是不够的，你的软件»好经得起时间的考验。 

第二，伟大软件是 设计良好的 (well-designed). 
编码良好的 (well-coded) 并且易于^护.重用及 

FK ~ 一 -— 

"it.— ㈤ 
当软件 S 于维护.重利用及扩展I 
时，你（和你的 同事） 会认为它 i 
是伟大的。 
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伟犬软件的简易三步骤 


良好应用程序的基石 


/. 确认你的轵 
件炒奢户要 





一 此孕律龙 重走爸户丄 •• 碡保左 

^i4<mtjti'iik(iti* iiw& 

歧祺常$ ( ir ^ uimnenf ) 寿激分科 
U»ilyais) 


c 


2.迗芹基本的00 
屏则奔增加轸 
件的炅 泠性。 


- Sfe 4 孖始注作.饬敍找出 
©苒 S » 戶法的重4蠖 
终代岛. *1!垛久你在僅用®妗 
的00鹐《 技术。 


«««它戊《二寧的 j 好®佘句 
S 的在用《埤..&吋領这用设外 
«式乌00琢則來 ii 係伪的致4 
:<1备《«5.它杏 今后几 專丨> 


•?. 努力实现可维 
护、可重芹的 
设计. 



还沱得 Rick 吗？沱得他流失的窖户吗？ 

U: 我们把如何编写伟大软件的想法脷 W- •下，看看它们是否能在真实世界 M 成 
iL . Rick 有个无法运作的搜索工具，你的任务就垃把它 《EU, 将它变成伟大之 
- K . N 头瞧瞧 应用 程序.€<符哪里出错了： 


iiiUttTt 
* I fl 奄闲 



采迗用我们的三步 骤吒: 


i & a . 我们必*由 
鉍认在用《存*的 
在鈹 Ri ■: fc 5靂栌 
$fHi . 根沪 S. 


.确认你的轸忤 
炒者户要它炒 
的亊。 


2.运用基本的 

加轵件的炅泠 

惟- \ 


沒 ci 个时同点_£« 太在 ■* •如坷将 
议 《•■>«! 式寿真玷00对术注用 
W 饬的在用中,. 


•? •努力宍琪钉维 
铲、珂*用的 
珙计. 








良好应用程序的基石 



找. t 个设, 呻 


Frank： 与然，这会修正 Rick 所遇到的问題，但我认为可 
能存£好的解法，而不是四处调用 String 的 toLowerCaseO. 
Joe： 是我也在想同-件事。我是说，比较所有的 
字符串似乎不是好主息。能不能在制造商与木料的特 
性 (properly) h 使用常 S 成者 •些 枚举类 5) (enumerated 
type) ? 

Jill： 你们 想太远 r. 第•步应该先炫改应 HI 程汴. It 它做 
到客户要做的 _K 。我认为设I十的寧还不川操心 . 

Frank： 坫啊， 我们应该先把热点放住客户身上.徂玷我们 
至少能够以聪明的方法来进行，对吧？我足说，如*能从 • 
开始就避免.为什么还会产牛.稍后得 M 头梭改的问埋？ 



Frank 


Jill： «. 合理。我们+要解决了问题，却产牛新的设讣问 
题。我们不会弄乱应用程序的其他部分，对 》E? 


Frank： 没错. 我们可以只移除那些字符串以及字符串比 
较，以避免 整个大 小写匹 K 之事。 


Joe： 完全 m 确。假如我们采用枚举类型，便4确保只冇有 
效的制造木料与吉他才会被接受。那么， Rick 的客 
户必然会 W 的符到符合他们®求的 A •他。 

Jin： «们真的间时完成 r -点点设计工作,太好 —n 咱们 


剡为3斛夬阳洵 
拯芮产生新汨越。 


步驟 1: 让客户满意 


矣 # String 比餃 


我们对 Rick 的吉他搜索工具所做的第一个改赛是去除所有烦人的 
String 比较.即使你能使用这样的函数来避免大小写 

的问题.我们还是选择完全去除 String 比较： * f f « 













良好应用程序的基石 


•1 尖你的铝 I 

" 将步骤1应用到你自己的项目中。 


是看看如何让你自己的客户满意的时候了《在下列空白中简 
单叙述你目蘭正在从事的项目（也可以使用最近完成的）： 


现在，写下当初开始该项目时所做的第一件亊。那件事与确 
保你的程序代码做的是客户想要的有关吗？ 


假如你一开始把焦点放在其他事情而不是客户上，想想看， 
你所实现的东西与知道伟大软件三步骤后再做的情况会有什 
么不同？不同在哪儿？你认为应用程序会比現在好还是差？ 


1^) : 因此进行步骤1时做点小 

设计无妨.是吧？ 

^: 是的，只要你的焦点还是 

在客户的需要上.在开始进行大的 
设计改 t 之前，你想让应用《序的 
基本功徒准备就绪.然而，在进行 
功能处 a 时.你确实可以使用好的 
oo 原則与技术来确保你的应用《序 
一开始便设计得良好， 

1^) : 第18页的 a 是一个类囹 
吗？ 还是多个类围？因为它 包含一 
个以上的类. 

V: 是一个类 B, 单一类图可 

包含多个类.事实上，类田所 ifti 
的*«节超过你 B 訪所見.我们会在 
下®几幸逐步增加这方面的信息， 

Ip ) :那么.我们已经准备好 
要移往步骤2,开始运用00原則了 
吗？ 

^: 不尽然……在开始分析《 

序代码、找出能改善的地方之前， 
Rick 还想要我们擊他完成一件事 • 
记住，我们的首要任务*取悦客 
户.然后才是真正杞焦点放在00 
设计的改善上. 







良好应用程序的基石 


Rick 的窖户想要有选择杈！ 

Rick Q 经为他的应用程序想到了一个新 需求： 他®捜索 J: 具返问 
符合客户规格的所有他，而不是库存中第一把符合的- 


_ Inventory _ 

guitars: List 

addGuitar(String, double, Builder. Siring, Type, 
Wood, Wood) 

getGuitar(String): Guitar -一 

search(Guitar): List 


姑句合$户<€ 路 . 我们 s 
iis * a,cA ()iS 阳多个 
' 吋象. 



；' 程序代码硪铥 

1 继续步 WI. 确认应用程序运作正确。| ( 面是 Rick 的库存工具中的 sear ch(> 方 
I法的程序代码，由你来填 h 遗漏的 片段。使 用斑面 下方的程序代码磁铁，从 
Rick 的库存中返回所冇符合客户规格的吉他。 

'Ublic _ search(Guitar searchGuitar) { 

_= new _(); 

for (Iterator i = guitars.iterator(); i.hasNextO;)( 

Guitar guitar - (Guitar)i.nextO; 

// Ignore serial number since that’s unique 
// Ignore price since that’s unique 
if (searchGuitar.getBuilderO != guitar.getBuilder ⑴ 
continue; 

String model = searchGuitar.getModelO; 
if ((model != null) && (imodel.equals(""J) && 

(!model.equals (guitar.getModelO))) 
continue; 

if (searchGuitar.getTypeO != guitar.getType()) 
continue; 

if (searchGuitar.getBackWoodO != guitar.getBackWoodO) 
continue; 

if {searchGuitar.getTopWood(> != guitar.getTopWood()) 








程序代码磁铁解答 


继续步确认应用程序运作正确.下面是 Rick 的库存工具中的 scarchO 
方法的程序代码，由你来填上遗漏的片段*使用恧面下方的程序代码磁 
铁，从 Rick 的库存中返固所有符合客户规格的古他. 





1 



I 1 ®) : 因此.直到应用程序像客户 

想要的那样运作才算完成步骤1 ? 

^ : 正螭。在你精心应用设计 
模式或 AB 进行真正的重新《构化之 
前，你要磯认应用《序尽了它的职 


l a J : 为何在进入步骤2之前完成 
步骤1是那么靈要？ 

^: 在你设法让 fc 件正确运作 
时. 你会对它做许多改 *. 在把基本 
功能定成之前，进行过多设计工作的 
企图最后可*变成一种浪费，因为许 
多设计可詭随屬你把新功能片段增加 
到类与方 法中* 产生改 *. 


Y °\ : 你好像有点执着于“步骤 

1” 与“步 *2” 的相关事务中，万一 
我的应用程序不以此方式编写又如何' 
呢？ 

V : 没有规定说你 必須定 •全 0( 
«这*步 《. 伍它们确实提供了一个 
可邊 垅的 S1 单路径.确保你的软件做 
它该做的设计良好 i* 易重 t 利 
用，若你有类似的方法 T 以实现的0 
标，也很好！ 
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谢试驱动 (Test Privc ) 

我们已经谈了很多关于从客户处取得正确需求的事， 现在 必须确 
保我们的程序代码确实处理了那些箱求。测试-•下，看肴疢用程 
序 是否像 Rick 想要的那样运作。 



a can have 

have a Par 


Aldac 

Aider 





运用你的 oo 原則 


诊到我们的步骤 

既然 Rick 已经接受我们的软件，现在可以开始运用…些 OO _ 
并确保应用程序存 m 活性 a 设计良好。 


/ •确弘 你的轸 
件炒者户要 
它炒的事。 


2.运芹基本的00 
屏则弗增>取 
件的炅泠惟„ 


3•努力 宍现钉 
維铲、可* 
痄的谀计《« 


Rick 畢.«砵豪* k 歩 

»■€ 



24 


良好应用程序的基石 


f 找问越 


再深入-•点探究我们的搜索]:具，看看是否有什么问题是简单的 OO K (則 
可以帮忙改»的.躭从史仔细苻 Inventory 里的 a «« C hO 方法如何运作 



-«#他 部含* 菩 

f 的 QuiMtrt 象 I 
的《格进«比的。 


讦晡 一 

| 这里有什么不对劲吗？ Rick 的 


捜索X具有什么问题？ 


: nm 细叻诫每 z ■姑 
矽裨* /* 务窍 --'sm 


客卢以 Q“it« 对象的形式為 
坫们《•中的理 SS 他接 出 一ffl 
«格„ 


客户不极供价格岛 


«- 


» 4 咢 




«•««/!() 方法由害户叇以_ 
铂《移讲用.纽«旮 Rie * 


Ricfc 的虞徉 1 6 1 . - 
有的在的*1*故《_ 象.得鶴寿 
*. 价格 A «6 格,. 



分析 search !) 方法 

花点时 N. 4f4f 分析分析 Inventory.java 中.的 a*arch<) 
方法 • if 程 序代码 之前， 先想想 此方法应该做什么. 


O 客户提供他们的吉他偏好。 -- ® 

Rick 的毎位客户在寻找现想吉他时都打.叫特性是他 ffl 4t. 

感兴®的： 使用的木料.吉他类型.特定的制造商或型号 
(model) 。他们提供这些偏好给 Rick, Rick 会将它们传给库 
存搜索工具。 

O 搜索工具查看 Rick 的库存。 

搜索工具知道 Rick 的客户要什么，便丌始循环遍历 (loop 
through) Rick 的庳存1的毎 -把 g 他。 


o 每一把吉他都会跟客户的偏好进行比对。 

对 PRick 的; It 存里的毎一把吉他.搜索1：具会它垃否符合 

荠户的 »4f。 «=比对成功，符合的吉他会被添加到®给客户的 辦嗲鳗用的 

选择列剔<， 破 會乘务 

穿户的《好 a 行比朽 

O Rick 的客户 获得一 个合意吉他的列表。 

最后， i« •:&；的吉他的列表被返回给 Rick 和他的客 户， 客户可 
以选择. Rick 有生息 J*。 


为 JE 在试窗斛夬的佝趑痄关字推 
达渌楚，确伢你的珙计与 应芹栈 
疼惣实现的功熊一舒:。 
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OOJI&D 



少年亊件薄 
粦型泛键 


在对象村的较佳设计区里,对象非常讲究 它们的 I:作内 
涵。毎个对象忠干自己的工作， 发挥® 大的能力.设计 
良 W 的对象厌恶 的亊铒 过于被用在其真正意图之外 
的范围中。 

遗憾的垃，这正是发生在 Rick 的库存捜索工具里 的事： 
在某个地方，对象正被用来做它不应该做的事。你的任 
务是解决这件神秘的事，并想出如何让应用程序走入正 
紈。 


为: r 帮你想出哪里出错，这里有些提示，帮你找出不匹 
配的对象类型 （objecttype) 。 


傳！ 翻 f ‘) 下一页 
个谜。 


1. 对象应该做其名称所指之事 

假如对象名为 -Jet" ,它可能应该是 WkeOffO 与 lando 
(起飞与降落）.而不该是 takeTicketO —那是其他对 
象的工作，小 WTJet 。 

2. 每个对象应该代表单一概念。 

不要 U； 对&扭负双1 [或任。避免使 111 一个 Duck 
对象來冏时丧示会呱呱叫的真正鴨子. * 色的®料鸭或 
者低头躲避以免被棒球打到的人（译注 2) , 

3. 未使用的特性是无用的贈品。 

假如你有一个对象经常有空值或 null 的特性，你可能有 
一个对象在做^种以上的工作。假如你的某个特性很少 
有值，为何该特性是此对象的一部分？要不要有一个较 
好的对象仅使用原有特性的子集 (subset) ? 


你认为这个不匹配的对象类型为何？将你的答案写在下列空白处。 


你认为该如何修踅此问题？要做什么改变？ 



重*的程序代码.逊！ 



/ 你 知邐埯 . KiekW* 户 * 

; a « a « 餐令知代虹对*。 «* 
v a . «们科*»的》«■-令* tt 对* 
( 采 A «« tt 対。 


Frank： m, 没错. Joe, 我以前没想到这 •点， 

Jill： 那又怎样？使用 Guiiar 对象 真的让 searchO 里的比对变得容 

S? 


Joe： 其他对象也行 ，瞧: 


乘令 Jnir«ntmy 的 


stuchOis •: tt 1 ) 
租*玲&。 


Joe： 我们在那 11 使用什么对象其实没有关系，只要我们能理解 


封篆 (encapsulation) it 

你 • 将应用栈存尹成 ― 徂 ― 


徂令乎逻轾的梆件 (»3 i ；. 


后爲 ® 瘃 ii! 嫌这往卞。 


Rick 的客户正在搜索什么规格即可。 

Frank： 足啊，我想我们应该有个新对象来存储客户想要送给 
searchO 方法的规格即可。那么他们躭不用传送 整个 GuUai •对象 ，这 
似乎不太合理. 

Jill： W&, 那不会产生重 M 的程序代码吗？如采有个对象夂门 
存储客户的规格， Guitar 便 会重复 所有的特性，我们就会有两个 
getBuilder() 方法.两个 getBackWoodO 方法……不好吧！ 

Frank： 那我们为 H 不将 Guitar 里的这些特性都封装 (encapsulate) 
到一个新对象中？ 

Joe： 等等，我 M 意你说的，除了你提到的 ■•封 装"。我以为那是 
当你要将所 有变& 私有化 (private) 以便不被别人误用时所做的事。 
那跟 Guitar 的特性有何关系？ 


►译注 3 : 


在本的 H 站上讨论到这段文字可以 
用*严谨的方式 fe 述.现在把这段话放 
在这里供读者 参考： 封装让你把应用《 
净部件的内部工作《藏起来，但是把部 
件在*什 么農示 得史清楚. 


Frank： 封装也是把应用程序分解成合逻辑的小部件，然后保持这 
些零件分离.就像侔将类屮的数据与应用程序的其他行为分开一样， 
我们也能将吉他的一般特性与真正的 Guitar 对象本身分开. 

Jill. 于是. Guiur 就只有一个变 S 指向存储所有特性的新对象类 
型？ 


Frank： 正确. -r •娃我们便 ft 的将,V他特性封装起来.放到它们自 
己的分离对*|卜。瞧，我们可以这样做…… 
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削尖你的绍笔创建 GuitarSpec 对象 

Via . 你会看到 Guitar 的炎 ffl, 以及 Frank, 川I和 Joe— 直在谈的 GuilarSpcc. 你的任务是 
把 GuitarSpec 所需的特性勺方法定出来.然后.将 Guitar 类不擗要的特性与方法去掉 .ft 
后，我们在 Guitai •类阁中留 F —些空间，以便你 增加任 何新的特性与方法。祝你好运！ 


Guitar 

serialNumber: String 
price: double 
builder: Builder 
model: String 
type: Type 
backWood: Wood 
topWood: Wood 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 



将 f4 何佚认妗鷹 
子新 QwC«S]ue 

* 的系® 



*的诱. 也 g 增 

灰《外的襄作鸟 
方法。 



GuitarSpec 






















* sscw …时象 耷害户 S 

1«供涂 《*•«(■() 方砝的系®之用的# W A 。 





GuitarS pec 
buiderMIder 
wodd: Siring 

_ 

baekWood.'Wood 

topWood-Woixi 


aetVullderO.NIder 
getModell): String 



gettopWoodOiWood 


荚的方法） 移 
«« 昀时 使用 
<5 禮索 

轚好的的 象中. 
扈的席代 


这整方法 a 祥耷林 的梭 
式：我们移 哙《何客户 规格务 
Q « u < 的象的重4。 


规在， E 新你 f 3 的程序代码吒 .r 


借此类图.你应该能够增加 Guit ««: Sp « C 突到你的应用程序中 
炸史新 Guitar 类.继续为 Inventory . j « v ■做 作改变.以便搜 
索工具能被正确編译 (compile). 
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- 

I ®): 我理解为什么需要一个对象来让客户传送规格给 
search () …… 但是为什么我们也用此对象存储 Guitar 的特 
性？ 

^ : «1 设你只是用 Guit « rSp«c 来存 6* 客户要送给 

s««rchO 方法的 規格， 并且保持 Guitar 类与;«先一蛘.若 
Rick 要开始铕售12弦吉他并 J ■想要一个 numStrings 特性. 
你会需要把此特性（及 getNumStringsO 方法的 C 序代 
码）同进增加到 Guitar 与 GuitarSpec 类中。你能明白这会 
导致重复的 e 序代碼吗？ 

相反地. 我们 将所有（濟在的）重复《序代码放入 
GuitarSpec 类中， 然后让 Guitar 对象引用它的实例以避先 
任何重 4. 

任何时候着到 

重 复稃序 代码，就找个摊方 

I ®): 我还是有点疑感. 这为何 是一种封装的 形式？ 能 
不能再解释一遍？ 

^ : 封装背后的想法是要保栌应用《序某一部分的信 
息免遭其他部分的干扰。在最简单的形式下.你能通过 iL 
数据私有化 （ private ) 来保护类中的数据，使之免遣应用《 
序其他部分的 干扰， 然而，有时该信息可能是一 S 组特性 
(如吉他的 *» 节） 或行为（如某特定种类的鸹子的飞行方 
式）. 

S 你杞行为从类中分解出来.你能改变该行为而无需改 t 
该矣.所以极如改 t 种性被存妹的方式，你根本不必改 t 
Guitar 类. H 为那* A 性在 Guitar 之外被对装， 

这是封装的* 责： 4过分解出应用《序的不 A 却分， 你範改 
t 一却分而不需改个应用《序。一般而言，你 A 该針装 
应用《序中变化可能很大的部分，让它们 it 离保 •! ♦不* 的部 
分. 


良好应用程序的基石 


#«我们在体丈炊件三，》中进 
行 《如何； , 


福认你的软件 
做窖户要 它傲的 


事。 


6 


2 .运用基本的 00 


原则采增加软件 
的炅话性。 

. 

( iaf 4^-94 

I 6 的沾方 .保 fi 

1 «4代《以双《■的 

1 *iS.H 


多.努力实现玎维 
浓 、玎重用的 
设 i 十。 

r 


i &( i . <5此歩》中我 fOSia 
<5* 多设分 曩激. 《以球 
來之《.你 
子# HAf 用， 
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更新 Inventory 类 

既然已经将吉 他的觇 格封装出来，我们必须对程汴代码做些改 
变. 


r 

现在 scatchOjft 金 
Qui(«S)»c . 代 @ 整个 
Qttitat 的象 .， 


guitars: List 
addGuitar(String, double, Builder, String, Type, 
Wood, Wood) 
getGuitar(String): Guitar 
search(GuitarSpec): List 


public class Inventory ( 

__" variables, constructor, and other 

' — 5k 

public List search(GuitarSpac saarchSpac) 


*< n *** R * J»m 

Qiiitai S.. 


代砝和 fe/ ■箱几呼一 
样.铨 5 现在戧们值 
用 fiuitatSpec fj ^ 

的 <SS 。 


List matchingGuitacs - new LinkedListO; 

for (Iterator i ■ guitars.iterator(); i.hasNextO; ) { 

Guitar guitar - (Guitar)i.next0; 

GuitarSpac guit « rSp«c - guitar . g « tSp « c (); 
i£ (8« archSpac . getBuilder<) !二 guitarSpec .getBuilder ( ) ) 
continue; 

String model = searchSpac.getModelO .toLowerCasel); 
if ((model !■ null) && (!model.equals("")) && 

<! model • equal s ( guitarSpec . get Model 0 • toLowerCase ()))) 
ontinue; 

if (searchSpac.getTypeO != guitarSpec .getType()) 
continue; 

if (searchSpoc.getBackWoodO != guitarSpec.getBackHoodO) 
continue; 

if (searchSpec.getTopWoodO != guitarSpec .getTopHood()) 
continue; 

matchingGuitars. add (guitar); 


return matchingGuitars; 


户《糌的本他列* 


I 




良好应用程序的基石 


准备另一个测试驱动 

你将需 要史新 FindGuit«rT.«t.r 类来测试所 
有的新 改变： 


public class FindGuitartester | 


ii - A . 吝户传 


public static void main(String[] args) { 

// Set up Rick’s guitar inventory 
Inventory inventory = new Inventory0; 
initializelnventory (inventory); 

SuitarSpac whatErinLikes = 

new Guit*rSp«c(Builder.FENDER, ~Stratocastor" / Type.ELECTRIC, 

Wood.ALDER, Hood.ALDER); 

List matchingGuitars = inventory, search (whatErinLikes); 
if (SmatchingGuitars.isEmptyO)( 

System.out.println("Erin, you might like these guitars:"); 
for (Iterator i = matchingGuitars.iterator(); i.hasNextO;)( 

Guitar guitar - (Guitar)i.nextO; 

GuitarSpac ap*c ■ guitar.g«tSp«c(); - - 

System.out.println(" We have a " + 我 (H 也 4 使用 

spec.getBuilderO + « » + spec.getModelO + 、’ " + 扣的 (^ju.Sp.c ft, 


spec.getTypeO 
spec.getBackWood <) + ' 
spec.getTopMood() + ~ 
guitar.getPriceO + ~!\n - ")； 

» 

1 else { 

System.out.println<"Sorry, Erin, we have nothing for you."); 


private static void initializelnventory(Inventory inventory) 
// Add guitars to the inventory... 


- 

你可以在 http://www.headfirsllabs.com T 栽 Rick 的拽索 H 月;的 
当前版本，进人 "Head First OOA&D '. 找到 “ Rick’s search 
tool with encapsulation ” 。 


g 

FindGuttarTester.java 
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♦ 逢终看？ T 

你 ii 经乍到很多 x p 编巧伟大软件的知 i 只， m 还冇史多知识在后面，做 
个深呼吸， 甩考一 下我们已经涵鏟的-•些术语和原则。将左边的词连接 
到右边的这些技术与厣则的 h 的。 


我.你无法让害户 无 论你的 
sroa 序设讦饵多》.让窖户脍上«出《笑 
的 aa 我。 

我很关心重用稃 a 碥保你进 布试* 蘚玦冥他 
^ 人 BJ2 藓决过的闷®。 


饽玎 认利两我挖《序 代铒中 31$的典分乌保 

If) 嘛付 f i , 31 jCflff ««8« 

不会 《«= Xte ® 分«变锝很容 R 。 




«两我，你 的软件 «能》$和成长《无*対 
«! 重®, it 你的成两《序免子臚 》. «»坏 
的*: X 。 


- ► 答# a*52R 。 

、穿问％® _ 


I ®): 封装不是我在此阶段所能运用的唯 _oo 原則 

吧？ 

^: 没错.在此阶段你会想要考*的其他 oo 摩則有 
继承 (inheritance) 与多态 (polymorphism). 这两个与重 
复《序代磷和封装郜 有关. 因此，从找出你 tt 使用封装的 
地方开始改善你的设计往往是个好主意. 

在 St 本 •《 中我们会诙到很多00编《原則，因此这时别担心 
你* S 完全掌极]■状 况. 在我们 tt 東之前，你将会 学到史 
丨关于封装，类设计以及其他方面的知识. 


1^) : 但是我并未真的看到封装让我的程序代码更灵 

活.你能再 解释一 下吗？ 

^ : 一旦你让软件桉照它该做的郅样运作之后.灵活 
性就 t 成一件大事 • 万一客户想要给应该 C 序增加新的特 
性与 功能. 那锊会如何呢？如果在你的应用《序中有很多 
重复的 《序代碼以及令人困患的鳐承 tt 构.将会是你 
心中的痛。 

通过为《寺代碼 引进诹 封装以及好 的类设 计这*摩改 
t 会 比较客 ft, 而你的应用《序也会变得史灵活. 




良好应用程序的基石 


诊到 Rick 的皮 用程序…… 

确认一下我们所做的改变没有弄乱 Rick 的工具的运作方式， 
编译你 的类，然后再运行一次 rindGuitarT«»t«rf；I'r： : 



« - 

I 你能想到三点，说明设计 ftW 的软件比内含 《K 
程序代码的软 件史容 ft 变逝吗？ 





做一些真正设计的时侯 

设次，设计两次 

■ a 你完成第•冋合并 a 运用 _ r 一些的 ooism . 你 
9»»好8||(向《进一步，这一次，你能确保你的软件不 
仅有泌活性.而且崧千®用及扩 ®。 


/确认你的取件 
炒麥户要它你 
的事。 


> •运芹 基本的00 
/ •»}：!) 来埤加软件 
的炅》悌。 


夂努 力实现可维 
铲、可重用的 
设计。 
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碥认一 *F Ihvcwtory.java 是设 i 十良好的 


我们已经使用封装改祥 Rick 的搜尜 .L 具的设计， m 程序代码甩 
还打.些地方轚去除潜在的问題，在 Rick 想到 "F— 个库存搜索 
_ I : M ： 的新功能时.我们会把我们的程序代码变得 容&扩 W . 而 
K . 假如我们想要在其他上下文 (context) 中使用应用程序的 
这几个部分，也会比较容 S ® 用它们。 


f 的 S0 料 ㈣ 幻-个 gci ⑽後 
… 111 ㈣ * 


public List search (GuitarSpec searchSpec) { 

List matchingGuitars = new LinkedListO; 
for (Iterator i = guitars.iterator(>; i.hasNextO; ) { 
Guitar guitar = (Guitar) i.next(>; 

GuitarSpec guitarSpec = guitar.getSpec (); 
if (searchSpec.getBuilderO != guitarSpec.getBuilder()) 
. continue; 




该怎样修改这段程序代码？ 

上面的程序代码有个大问題.你来想想问题出在哪儿。在下列空白处写下你认 
为的问埋所在以及如何改进. 







改变简单吗？ 
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GuitarSpec 
builder: Builder 
model: String 
type: Type 
backWood: Wood 
topWood: Wood 
getBuilder(): Builder 
getModel(): String 
getType():Type 
getBackWood(): Wood 
getTopWood(): Wood 


为 Rick 的类 E0 进行⑽。 的绍 I 

Rick 想要买 12 弦吉他•拿出你的铅笔，枪 ' 

类 ia 增加注解以 a 示下列 事项： 

1. 在嗛甲.增加称为 numStrings 的新特性，以存储-占他的弦数？ 

2. 在哪甩增加称为 gelNumStringsO 的新方法，以返回吉他的弦 
数？ 

3. 你认为还有什么其他的程序代码需要改变，以便 Rick 的客户 
指明样式是12弦吉他？ 

最后，在下列空白处写下为12弦吉他增加支持时所发现的设计 
问题 • 


1 

-褚•子在 V * 岛 

_ Inventory _ *37两工■的夺癯 穷关系 

guitars: List 

addGuitar(String, double, Builder, String, Type, 

Wood, Wood) 
getGuitar(String): Guitar 
search(GuitarSpec): List 


Builder 

[toStrinj 

_ 1m _ 1 

| toStrinc 

Wood 1 



toStringO： String 


潑，洳 * - 

使用 numStrings 特性，而不是只 
增加指出是否为12弦吉他的布 
尔特 性的好 处是什么？ 






为 Rick 的类图进行汴 解。 

Rick 想要买12弦吉他 * 拿出你的铅菴，给类图增加注解以 
显示下列 唞项： 


I. 哪31增加称为 numStrings 的新特性. 以存储占他的 弦数？ 


2. 在哪 (R 增加你为 getNumSiringsO 的新方法，以返 M 吉他的弦数？ 


3. 你认为还有什么其他的程序代码需耍改变.以便 Rick 的客户指明样式是12弦吉 
他？ 


敁后，在_卜 _ 列空白处写下为12弦吉他增加支持时所发现 的设计 问题。 

我们增加特性到 fruitarSpee , 

侄是必兔妗改 Inventory 类的 

search ㈠ 方法认及 frultar 类的构 _ 

壜&数中的 g 序代_ [ - 5!!!*!!； - 


iif * 我们 的夺 
*. 饬 SHit 似的.承® 
■ 3 咚: 


jumt 

獒坩知” 昶 


serialNumber: String 
price: double 
spec: GultarSpec 
getSerialNumber(): String 
getPrice(): double 
selPrice(float) 
getSpec(): GuitarSpec 


戧们 笔#琏変此类 
的构©巧 
总孩受 QuitmSpec 的 
«« 鞾作 . MEt 
Ztf) GuitarSpec f) 


4fc ft 的 方法 <£• 公 

料乜也备峰 € 此*法髴* 
At -这芍4个问®. 





没错——我们需要封装吉他 
规格， 将它隔离 于 Gik 的搜 
索工具^ 


即使你只是增加特性到 GuitairSpec 类, 
还是 有两个 其他类必须被 修改 ： Guitar 
与 Inventory 。 Guitar 的构造函数 H 前 
—必须接受额外的特性， Inventory 的 
MarchU / j •法也必须做额外的特性比对。 


扑构 it 函教 6_J t<imu,Spec 




珙计#戽 

知道 Rick 的应用程序有什么问理，甚至知道我们需要更多的封装是不够的。 
现在， irtft 需要真正想出如何修改他的应用程序，使其容易重用及扩展， 

问题： 

增加新特性到 GuitarSpec . java 导致 Guitar , java 与 Inventory . 
j « v •中的程序代码的 改变。 应用程序应该被重新结构化，以便 
增加新特性到 Guit * irSp * C 时不会彩响应用程序其他部分的程 
序代码。 

任务： 

❶ 柄加 numStr inga 特性和 getNumStrings 0 方法 jHjGuitarSpec. java 。 

0雎改 G U it « r . j » v « 以 f ( EU ： Guit « rSp « C 的特性从此类的构造闲数中被 
^封装出来。 

Q 改变 Inventory . java 中的 search 。 方法，将两个 GuitarSpec 对象的 
比对委托 ( delegate ) 给 Guit « Sp «:* ,而不是直接处理该比对„ 

- O S 新 FindG U itarT M t «. j « v «, It 它使用你的新奥，并确认毎件亊 

免的 Q “ •⑷构 逢 还是正确运作。 

O 将你的答案弓第44芮的结采进行比较，接宥准备另-•测试驱动，看 
看我们是杏真的完成 T 此应用程序。 


T-fitfj 

0.06 

(Jelegalion) 

««c»r 



I ®) : 你说我应该把比对 =工作•委 ( o ) : 

托■■给 GuitarSpec, 什么是 委托？ 

^: 委托是指当对象需要执行某項工 

作时不直接进行该工作，而是要求》—个对 
象代为处理（或者有时只是针对部分的工 
作）. 


良好应用程序的基石 

委托与程序代码比较可以重用有 


何关系？ 

^ : 委托让 条个吋 象自已去担心相 

等《 (或 莱种其他工作）.这表示你的对 
象彼此独立或者是比较低鎢合的 （loosely 
coupled ). 低耦合的对象能从一个 应用程 


所以在■'设计抖 图''中. 你想让 Inventory , 
java 的 search 0方法请求 GuitarSpec 来 
辫别两个规格是否相同，而不直接在 
search (> 方法内比对两个 GuitarSpec 对 
象. search (> 方法将比对的工作委托给 



r®i :重点是什么？ 

^:委托让你的•代瑪*詭 重复利 
用. 也让每个对象关注&己的功能，而不是 


序中被取出，然后轻易在》—个应用《序中 
被重用，因为它们并未*密联系到其他对象 
的程序代码。 

I®): 低耩合 是什么意思？ 

^:低《合意味着应用《序里的各个 
对象各有特定工作* 做， 而 i 只徵邶項工 
作‘因此庄用《序的功能被分教給许多定 
又良好的对象.它们各 ii 将拳一工作敌得很 
好. 


把处理单一对象行为的《序代碼分散 在繫个 
应用《/»•中„ 

JavaSjft 普通的委托范例之一就是 
equals (> 方法。不是在方法中考黃两个 
对象是否相等，而是调用两个对象之一的 
equalsO 方法并传入第二个对象，接着从 


为什么那是好的？ 

低耦合的应用《序通常比较有灵 
活性.且容易变更。因为每个对象都很往立 
于其他对象，你可以改变一个对象的行为而 
不必牵动所有其他对象，所以增加新功陡或 


问： 

答： 


equals () 方法得到 true 或 false 的响应。 特色变得容易多了。 

「聲聲 @■'0^ -- 


I 邊 « 


个的象将 孫行鞾 交给另_个 
象的劫 (1. 第二个对象代表 第一个 
3象执行找換行。 



设计拚爵解者 

知进 Rick 的应用程序有什么 H 哩，共 柬 知进我们盅要更多的封装是不够的， 
现 / K . »$1 志要真正想出如何修改他的应用程序.使其容用及扩城。 

问题： 

增加新特性到 GuitarSpec . java 导致 Guitar , java 与 Inventory 
.3* v * 中的程序代码的改变。应用程序应该被8新结构化，以便 
增加新特性到 GuitarSpec 时不会彩响应用程序其他部分的程序 
代码。 

任务： 

❶ 增加 numStr ing ，特 性和 getNumStrings (> 方法到 GuitacSpec.j ava 。 



public class GuitarSpec { 

// other properties 

private int numStrings ; 

public GuitarSpec(Builder builder. String model. 

Type type, int numStcings , Wood backWood, Wood topHood) 

this.builder - builder; 

this.model = model; 

this.type = type; 

this-numStrings = numStrings ; 

this.backWood = backNood; 

this.topWood = topHood; 


" Other methods 


public int getNumStrings () { 
return numStrings ; 



4 


GuitarSpec.java 
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现 4 戏 *不 4 

在构逢&教 中釗 4 —个。 


O 改变 Invantory.java 中的 M*rchO 方法，将两个 GuitarSpac 对象的比对委 
托给 GuitarSpec 类，而不是直接处理该比对 . 


matchingGuitars.addtguitar), 

matchingGuitars; 


public boolean matches(GuitarSpec otherSpe_ 
if (builder != otherSpec.builder) 
return false; 

if ((model != null) && (!model.equals(''" , >) 
({model.equals (otherSpec. model))) 







最 后的测试驱动 
(应用程序准备好重用） 


哇，0从 Rick 将他的访•版古他应用相序 展尔给 我们吞以来， 
我们已经完成I •许多 n 作。来肴看 ft 后这一版蛙沒仍然止碥运作， 
并目.满足我们自 d 的 B 标： 拥有一个设计良好.弈》维护目.可® 
复用的应用 程序， 



%java FindGuil 
Erin, you mig] 


We have a Fei 
Alder bad 
Alder top. 
You can have 


light like these guitars: 

i Fender Stratocastor 6-string electric guitar: 

back and sides, 

top. 

lave it for only $1499.95! 


Alder back and sides, 
Alder top. 

su can have it for only $ 


H 长 ㈣ 


Qi ** 你 找柳邮 雜厲存摈 
h 郎郎”轉计良势 
MM 的 体轉件 片段。 



良好应用程序的基石 


该颜來时路 


回 • 又肴石我们蛙如 Hlk Rick 的搜索 3 ：具变得这么 
好的： 


ifi 的一费功钺闭胜科 


工崎撕功^” J 
蝴的饮件 tM *- li 


我 们《銥坩加功翁.芘 
溲索找这®_个吉他列 


/. 确 t / •你的软件 
在炒著户要它 
炒的事。 


****«"«** **** 2.运痄基本的00 


屏则弗 增加轶 
件的炅洚性。 


莪们也将吉他的 耗乜封 装出 
*■■ 磘保给在用《埤坩 
釦供》乜4容異的， 


致们 SS 坩加 凌托以 值让我_ 
们的的象 A 此拉妗独在 . 4 一 
H«ftf !<•)»• 


夂努力实现可维 
铲、可重芹的 
设计。 


当前位 * ► 47 



论得迖 个玎伶的象仗鸣？一 



他只想写出伟大软件。 
那么答案是什么？你如 
何 贯彻始终地 编写出伟 
大软件？ 


你需要的就坫•组可遵循的步骤， 
以确保你的软件能运作并II设I十良 
好，就跟我们用在 Ride 的应用程序 
上的 飞歩® —样简吶*你只黹要某 
种打用的东西，并 a 能用仵你所存 
的软件项目上， 


> 与^■帮助 

你写出伟吴致件厂每一次。 

这•整段下来我们一直在谈论供你 
遵循以编驾出伟大软 件的三 步猓， 
我们一直在I寸论的就是 OOA&D。 
OOA&D 真的只是-•种编 W 软件的 
方法，它*热在确保你的软件做它 
该做的事并 F1. 是设计良 好的. 这表 
示你的软件冇碱活性.容 ft 改变. 
W 维护并&可*用， 





良好应用程序的基石 


00 A 邛兵系到编写体大软件， 
而不是一堆书面工作 r 


当应用程序正常运作.客户是满意的。 

r >我们可以从客户那甩取得擗求以确保我们依客户要求达 i 应用 程序。 
用例 《) 足做这件亊的好方法，它把客户想要应 用程序 做仆么粮理出 
论来. 
t 求. ° 

当应用程序持续正常运作，客户是满意的。 


%U?.To 


没有人会喜欢应用程序三天两头出问题。假如我们的应用程序设计良 
好，它会很强健。而且即使毎次客户都以不寻常的方式使用它，也不 
会 损坏。 类图 （class diagram) 与順序阁 (sequence diagram) 能帮我 
们看出设计上的问埋，但重点是写出设计良好 E 强健的程序代码。 



子4托.含成及 
| [含的扣<?•嗜 
我 们金在 # 5 肇分 
钵 aWii** 念 . 
然后 
光_下。 


当应用程序能够升级.客户是满意的。 

没有什么亊情比客户要求增加简单•新功能，却被告知必须花25,000美 
元以及两个礼拜更糟糕！ 使用* 封装.合成 （composUion). 娄托之 
龙的 OO 技术会让你的应用程序好维护 a 可扩展， 

当应用程序能够被重复利用，程序设计师是满意的。 

你曾经为一个客户逮立过某个软件，然后息识到可将它完全相同 
地运用在另-个客户的身上吗？假如你确实对应用程序做了分析 
3：作，通过避免各种不干净的依赖 (dependency). 实际上不潘要 


的关联 （association) ,可以确保它们很容易被重复利用。如开关 


原则 (Open-Closed Principle, OCP) 以及单一职责原则 (Single 


你《 在弟 8 f 看 
«这螫《«大 


Responsibility Principle, 
~~ ?• ^ 


SRP) 之类的槪念在这一点上也是很好的帮 


当应用程序具有灵活性，程序设计师是满意的。 


有时，只要一点镦构 （refactoring) 也能将好的应用程序转变成很捽的 
框架 （framework) ,运用到各种不 |a| 的事情上.这是你从一个埋头苦 
干的程序 员蜕变 出来，开始像 K 正的架构师那柞思考（足的，这些家 
伙的钱可比你多不少）的地方。综观仝 W (big-picture) 的思考就坻仵 
这儿 • ^ _ 访视含 

S }". 苒妗伪的痊用《存*杨科 


ii 舦4 00A&D , 
这#不4一曲* 
聊的®表 . 》 

4的在用 杻序. 
让客 户骞兴 . 让 

t 6(# 砉。 



重点回颗 



除弱的应用程序是很容易出错的。 

你能运用像封装与委托这样的 oo 原则违立灵活 
的应用程序。 

封装将你的应用程序分解成逻辑部件。 

委托将处理特定 r 作的贵任转交给另--个对 
象。 

总是通过整理出客户要什么来启动你的项 n 。 

-n 完成*本功能，就 t 新细化你的设计，比 
它史忒话. 


有了符合功能并具有灵活性的设计，便能运用 
设计模式进一步改善你的设计，让应用程序更 
容易重用。 

找出应用程序经常改变的部分，试普将它们与 
其他不改变的地方 分开。 

建 i 运作无误但设计不良的应用程序满足了你 
的客户，却给自己留下 i •痛苦以及无数 个嫌改 
问趙的+眠之夜。 
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面向对象分析与设计 (OOA&D) 提供•种产生 
设计良好的应用程汴的方法， 1-1 时 满足 客户与 
程序设计师。 




良好应用程序的基石 


燦 OOA&D 填字游珙 

使用已经学到的东西，动动你的左《。下列字谜的答案全包 
含在本章 M , 祝你好运！ 



横排提示 


竖排提示 


4. These help you avoid solving problems 
someone else has already solved. 

7. Customers focus on this part of your 
applications. 

8. Objects in loosely coupled applications are 

more_than tightly coupled ones. 

9. Flexible applications are usually easy to 

10. This is one type of cade you don't want to 



12. Your applications should be easy to 

13. You usually need same sort of process to 

write great software_. 

14. Encapsulate what__ 

15. These types of applications satisfy 
programmers. 


1. Once yow application works correctly, focus 

2. Srouping your application into logical parts. 

3. The god of OOAdD is to help you write this 
type of software. 

5. Use this to let objects focus on more 
specific tasks. 

6. A good way to avoid duplicate code 

7. An application that things can 90 wrong in 



It. This is a four letter word your mom will be 
proud you know. 
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习题解苔 


♦ 0 ♦ 

♦ 逢终卷？ 

你 Li 经学到很多关伟大软件的知 UI, m 还有 E 多知识在后面•做 
个《 呼吸. 思考 .T 我们已经《盖的一托术 1S 和原則 • 将左 边的阂 连接 
M 右边的这钱技术与原則的 H 的. 



9涯 
»答 
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2 收集熏求 



给客户所需之物 


每个人都想让客户满意。 你已经知道编写伟大软件的第一个 
步骤是确保它完成客户要它做的事。但是如何理解客户真正要什 
么？如何确认客户真的知道他们要什么？这就是良好需求的着力 
点。在本章，你会学习到如何确保你所交付的东西确实满足客户的 
真正需求， Lt 你的客户 满意。 ff •你完成之时，你的项目将是“保证 
满蒽”，并且你也将步上编写伟大软件的永恒之道。 



大显身手的机会采 7 

你刚刚被 Wirt 为新项 R "超棒狗门”的苜席程序设计师. Doug 
& ••超拌狗 fr 的老板，他正在开发•种»亮的高科技门。他决 
定由你担任程序设计师，编写软件，比那超棒的 硬件能 运作. 




收集需求 




我们需 要的第 一个东两是表示狗I’】的类，就叫做 DogDoor. 捋加 i; 几个 
方法： 


public class DogDoor { 
private boolean open; 


public DogDoor() { 
this.open = false; 


级设 °ofOoat 类将粉演 




« public void open() { 

System.out.println(''The dog door opens."); 
open = true; 


. 

*0. 


> public void close() { 

System. out. print In (''The dog door closes."); 
open - false; 


nw 杖态 .. 


public boolean isOpenO { 
return open; 


’••却 <5 OojDooi , jtim J... 



C DogDoor.java 

的狗 ni 的坟件。 


说 U“. QiwliiA 你的老 
板 Oo“》 
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为狗 n 写代码 



程序代码€铁 

咱们来写另一个类， Remote. 让通控器操拕狗 fl。 
Todd 能用此遥控器打开狗门而不必起床. 

汴意，你"了能不黹.嬰用到所有的磁铁。 


public class Remote { 


private 


door; 


我 (0 知 ( Cii 罹容, 



public Remote (_ 

this.door = door; 


public void pressButtonO ( 

System.out.println(''Pressing the remote control button..."); 

if (_■_0) { 

door._(); 

)else { 
door._(); 


- s 完成.乌* 







收集需求 


测试驱动 

看看一切是否正常运作， 测试 •1^你的新狗广|， 


O 创建测试狗门的类< DogDoorSimulator.java >。 


public class DogDoorSimu 1 ator { 
public static void main(S£ring[) args)( 

DogDoor door - new DogDoorO; 

Remote remote ■ new Remote (door); 

I System.out.printlnl'Fido barks to go outside..."); 

I remote.pressButtor 

itln(''\nFido has gone outside..."); 




pressBuCtc 

out.printl 

,pressButton< 


(~\nFido's a 




DogD&rSimulator.java 


O 将 Java 源代码编译成 .class 文件。 


DogDoor.java 

Remote.java 

DogDoorSimulator.java' 



DogDoor.class 

Remote.class 

DogDoorSimulator.class 








神么，霈求究竟長什么？ 


•■场 t 求 a » 4 -4 相 

4 W 事. 

蛘蓽染 fi 认伢 4 WWi 
<_«# 求. ______ 


■ t，s a (译注 2 > 


specific thing 


your 


■ s ,,um' (系统） 4 你 i<S 
择0 的* 个6用技存残场 
0 ..旮 rt 例中.你的系统 
s To<U AQi »* 的螫个狗 n 
；2 «r (fe 食 ii «8> „ 



麴 n 系垅必场 ■办■(礙 ） 根 

? * ^n. Mn. ii 

^ 0 < 24 -择 J 螭疰 rf*(g 
*••-•« (9 To* A< .,„ gfiJ{|fl 
** ti..Uit ~ io - 


work correctly. 


聲賴聲 


' z(i - 系速注 n 的 a 砝鸟 s-a 由 f 户功金的: ® 

it. n^cr-ctsfgjiti^-t j isct.« 



f 求： 電求昱 荦一的 電鋈 . 锊刼戊明猝定户品或 
服 务在找 @的事蚤常用在系统王 伎或欽 4 i 枝 
兩正式用该中。 





收集需求 



O 收集狗门 的霣求 （ requirement >。 

o 整理出狗门真正应该做什么。 

O 取得任何我们需要 Todd 
及 Gina 提供的信息。 



O 把狗门建对！ 


$(皋*^的今痒 1 . 
不&峰 ： 


/. 确认侪的轸件炒 
寮户要它你的事„ 
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tel , S & ina 试兩时 



►燁注 V 实上 1 予不* 于 TUSH . 而是* •形 I )的科幼物. ■•*■ 吡是 噠的意 s . 喵齿 J ) 劝物的上下*各有一 
对恍刊的 n 齿，很会哨糸西并且不淨地生长.所以上下门金必«不断*檫或噌校物. itv h 劝物也有这 
祥的门*.不过在其上 領大门 齿后面还有 一对较 小的门齿，这是 *« 齿 a 根兔形 b 最4著的区别. 




收集需求 


倾咁窖户 

谈到盂 求时錢 4 fit 客户自 己说。 仔细听，注意系统需要做什么，稍 
后洱整 ffl 出系统该如 H 做这 些事。 




■ o •你的《存代 


fido«12R 寸(1«+*2.54 

«表） *•* 们讦不》比它 fi*a* 

»n. ffiHff 。 


Gina : 我们想 it 门在几秒钟后自动关闭，我可不想半夜起来关 
狗门。 

你： 你想让遥控器只有一个按钮，还是两个按钮分别控制“开” 
和“关”？ 

Todd : 嗯.如果门总是会自动关闭，其实不需要分“关”与 
“开’ 按钮吧，用一个按钮就可以了. 

_你 ： 坫的 • fl 卩么，若门是关宥的，按卜•按钮开门（几秒钟后自 
动关> • 若门是 开笤的 （假 如门被 卡住的 话）， 按下按钮关 门。 
Todd ： 完美， Gina, 你还想到了什么吗？ 



Gina ： 没有，我想就这样吧。那就是我们梦想屮的狗门 • 



这1&饬棵隽 

ToiW 

求的*逢控 
■ 器耷狗 n 。 ' 


•口•有一个拍 £ S . 4 幵门 

鳥兴0之用切相. 


狗门，皈本2 


当前位霣 ► 63 


简单的需求列表 

釗建熏求列表 

既然知迫 Todd 及 Gina 要什么， It 我们写下•组新需求，不必太花 
哨. 


r 

656 ft «(*«■■ 

«*我们 如何辑 
他们的 叇鞾痂 A 
-< B * 本*求 



Q iU 

%/K. 
內认为要 


利大设锖 


dff .. 除了拥伤完成 Todd 及 Gina 的狗门所忠做的唞悄列 
:外， 你也 '" J ■以让你的老板确叻知进你 iKft 做什么，以及你 
' M 轚完 成项目还有哪呰事要做。 
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收集需求 



«4 


尖你的铝 I 

关于狗门，你认为 Todd 与 Gina 可能想到哪一类事情？把你可 
能考虑到的事做成列表，确保 Todd 与 Gina 会喜欢你正在为他 
们建立的新狗门。 
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c 

冶*事® f .)$. Td ■(岛 4«也»惠 


t 求列表 

Tbdd 乌识肋的狗 n . 胳水 9 n 
狗门傲的事 

1 . Fido 在叫，吵著要出去。 

2. Todd st &ina ' Hf'J Fido 在叫。 

多 . Todd 或 Wna 按 " F 遥控器按钮。 

斗.狗门打孖。 

5. Fido 跑出去。 

6. Fido 办它的事。 

ZRdo ® 采、进门。 

篇•狗 Ht 动兵闭。 


狗 niiEf 要傲什么？ 


你知道 Todd 与 Gina 要狗门做什么，而确保狗 f| 能实阮运作也是你的*任。 
在此过程中，你 K 至会想到一些 Todd 与 Gina 想要却没钉考 虑到的 事。 
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Todd 鸟 Wwa 的狗门，皈本 2.0 



SU6 



收集需求 




1^1 : 所以一项*求就*客户要应 
用程序 做的一 件事？ 

^ : 事■实上.需求远超过客户想 
要 的事一 * 然那是个好起点。从找出 
客户想要或期®的事以及他们认为系统 
应该为他们做什么开始，然而，还有史 
多事要想…… 

记住，即使问«发生了，多数人还是期 
S 事情*运作.因此你必《有心理准备 
某姿事可能会发生嫌误，从而增加解决 
这® 问题的 需求._«»好需求 * r 不仅* 
*户告诉你的亨，还要碡保系统总是能 
运作.甚至是在不早常或出乎意料的环 
境与使用情况下. 

1^) : Todd 与 Gina 的系统只是狗 
门，对 W ? 

^: 系统是为实现客户日标所需 

的每一 件事。在此*例中，系统不只包 
含 ft 门，还包含遥控 》• 没有遥控器， 
狗门就不会是完整的. 


1^ : 我不憧为什么必须想出 Todd 
与 Gina 会怎样使用狗门以 S 会出什么 
错误.那是他们的问题.而不是我的 
吧？ 

^: 记 得我们 诙到編写伟大软件 
的第一个步*玛？ 你必埙 确保应用程序 
像客户想要的那样运作，即使那不是你 
使用它的方式.这表示你必《真的了解 
系统要做什么以及客户将如何使用它， 

事实上，确保你为 Todd 及 Gina 做的狗 
门能成功运作的唯一方式，就是比他们 
£1•解系统并且确切了解系统要做的 
亨 .. 接着. 你 t 以《先考 *»r 能的问 
题，希《在1"0<111与 Gina 知道某事可能 
出错 （译注 3> 之 tt 解决它们. 

I®) : 那么.我该想到 Todd 与 Gina 
使用狗门时会发生的各种坏事吗？ 

^ :正确！事实上，现在就来做 

•C.. 


即使 Todd. Gina 与 Fido 不是系统的一 
部分.他们也都是在设计系统时必《考 
A 的事. 蜱 以有很多穿*担心，而不只 
是实体 的约门 本身. 


取得好霈 
求的最偉 
方式韌是 
: J 斛系银 


译注3:在本章. -*«• 是指用例置 .# 換路 ft. 的飧况.也就是情不根《 •■主要路椏 • 进行的 
惰沈. 
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收集需求 


4的 6 外。 


狗门打开 
i) Fido 跑出去 


卡 fi 时 

料 4硬相问 g.. 


万 一 Fi / o 冷龙寧 ® 柒 

B4#nsgt^Mx- 

5*： 



祭狳路径 (alternatepath) 

处理系统的疑难问越 


既然 巳经 想到 - 些会出错的怙况，你必须史新 it 狗门运作所耑的的列 
让我们写下万一狗门在 Fido 回来时已经关上会发生什么？ If。 



1.狗 


1 M 

6 t 

n 


3 .- 

*.7 

-« 子争 i * _ 

t 

4歩 *6 
的一郝分 3 


dtiofido 琦窃外 ®. 
奶 tf _费《4的 
4薄让它进床.这 
签* *4 的歩漱 

f 

1 


这*耷 * 64 Si <6® 的 f 
鈿 . ««E<5£2*Cs/# 


Todd 及 aiwa 的狗门，皈本 10 j < 

~~索求列表 

_ 色如乌识肋的狗门，皈本 2.0 
5门做的事 

1. Fido 在叫，吵着要出去。 

2 . Todd §5 &ina 听到 Fido 在叫。 

多 .Todd 或 W»ia 按 7 遥控器桉钮。 

4■. 狗门打开。 

5 . Fido 跑出去。 

6. Fido 办它的事^ 

© 狗门 f 动兵闭。 

6.2Fido 在叫，沙著要进来。 

6 .多 Todd 或 &ina 0 斤到 Fido 在叫 (再一 

次 ） 。 

6.4 Todd 或 Wwa 按 " F 遥拉器按纽。 

6.5 狗门打孖（爯— 次）。 

ZRdo ® 来、进门。 

名 • 狗门食动兵闭。 


) 坧有这费争痒钍 
fiFdo © 乘箱狗 n 
3® Mi •的伐*。 


~/味外的步 

LT iTodd ^ 
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收集需求 
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什么是用例？ 


( 爯次）介绍用例 

到0前为止.你已经用了几乎10页的®幅在写用例。但是，让 
我们更仔细地这个步骤列农到底是什么—— Todd 与 Gina 的 
狗门的坩例： 

A use case describes 


用例 4 …子、匕 （付 
的： 

igi(i 现«不*筘心 hB \ 




what 

your system 

does 

to accomplish a 

、 particular 


我 ( H 2* 钩砝蟪 《：« 在系 
统 t« (*) 


(#13 挝爲® 


故如 To “ 岛 ■'* ® ^ 

坊 f , j 0 使用隽 n 的汶尨.呷 
就 ■& 不的0钤.因此你* 
爱另一个； T 80的 用剩： 


customer goal. 


用户 （ k ， 沄 用户） 倍子帅 
*不&它«)-和分-- F ‘“ 值用 H 
«它 4( S # •绝=外：如 a 的系谈免* 
求，姑也&6系谈匕外. 






收集甭求 




一个用例.个部分 


—个用例，三个部分 

一个好的用例钉•:个基本部分，假如你要 U: 用例能完成工 
作，这 H 个部 分全都 黹要。 




收集需求 



程序代码磁铁 

下面足 Todd 与 Gina 的用例 • 以及好用例部分的磁铁 
(起点与终点分成两个磁 铁）。 你的任务娃把每个磁铁将 
要放人用例的位置标识出来. 


Todd AWnaW 轉门， life 本 2.0 
构门 做的擧 

1 . Fldo 在叫，砂著要出去。 

2. Todd 或 frina 到 Fido 在叫。 

3. Todd 或 & ina 按 " F 埵垃 g 按钮。 

4. 狗门打孖。 

5 . Fido 路出去。 

6. Fldo 办它的事。 

6.1 狗门6动打孖， 

6.2 Fldo 在叫， 砂簷 g 进采。 

6.3 Todd s 5 &ina "ft S'l Fido 在叫(爯一 
次）。 

6.4 Todd 或 Wna 按 7 遥控器垵钮。 

6.5 狗门打孖（再一次）。 

/ Fido ® 采、 迸门。 

丨狗门 t 动兵闭》 



•子.《中的一个4不 


刺 w* 个: 

m 磁狭故«用 碑让以，出; 

0他其个《分《推出糾 tfUCM 

分的 Tons . 0 , 1 ^ ■&明 filW 价 


3 将丹 4用句.，3當4 
在铯4部的 j ! 个**作 
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用例的各个部分 


B 


用例磁铁解答 


T>lfilJ4Todd 勺 Gina 的用例，以及 R4f 坩例飞部分的磁铁 
(起点弓终点分成两个磁铁）。你的任务垃把毎个磁铁将 
要放入用例的位 Sfc 识出来， 


Todd 及 ( Mna 的构门， K 本么0 


狗门戗的擧 

W c ——^ 吵着要出去。 


这4用埘的科始 


2. Todd 或 Wna 咁到 Fido 在叫。 

3. Todd 或 Wna 垵 " F 逞控器按钮。 

4. 狗门打孖。 

J . Fido 跑出去。 


6. Fldo 办它的擧。 

6.1 狗门 t 动兵闭。 

6.2 Fido 在叫，吵畚要进來。 

6•多 Todd 或 Wwa 到 Fldo 在叫 (再一 

次）。 



6.4 Todd 或 Wna 按 T 逯控器按纽。 
6.5 狗孖打孖（爯一次）。 

ZFido 矽来、进门。 

8.狗门 t 劫兵闭。 




Fiio® 寒. OMi 
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收集需求 


、術'匈埋 


I ®): 所以.用例就是系统为正确 
运作而必须做的步驟列表？ 

^: 在多数情况下.是的。但 

是.记住.用例的要点之一是把焦点 
放在完成一个特定目标上 = 若你的系 
统做一件以上的事婧，如让 Fido 出去 
并且记录一天共出去多少次，那么你 
就需要一个以上的用 «. 

IpI :那么.针对毎 一个完 成的目 
标.我的系统都有一个用例.是吗？ 

^ : 正确！ <11如你的系统确实 

只* 单一事惰，你或许只需要一个用 
例。》如它做10忤或15忤事.你会需 
要许丨用例。 

1®) : 用例是系统为完成目标所做 
的事_? 

^ : 没错.你明白了。 te •如你写 
下系 tt 为完成*任务所需做的事.你 
可陡已 a 取得了用例。 


1®) : 然而用例不是非常具 

体.我们为什么不谈谈 Remote 类 
或 DogDoor 类？ 

^ : 用例 试着帝你理 解系统 

该做什么——往往 T 以向别人 （如 
客户或 老板） 解释该系统。若你的 
用例把焦点放在《序代码层的具体 
细节上，对任何非《序3是没有用 
的。一般而言.用例座该用简单的日 
常生活*言. 《• 如你使用许多«« 
术谱或技术性行诺.你的用 W 很可能 
太过切节化，因而失去作用. 

I ®): 用例与用例图相同吗？ 

^ : 不.用例遢常是步*列表， 
而用例图是以 ** 化的方式 i 示用 
例，然而我们以6己的田表显示系统 
如何运作 （1 习一下»69 。不 

过.别担心.我们还会在第6章看到用 
例图。 


I ®): 那我如何将用例变成真实的 

程序 代码？ 

^ : 邪是应用《序《写流《里的 
另一个步朦。亨实上，我们将会在稍 
后的几贝里看到如何以 Todd 及 Gina 的 
用例史新我们的 C 序 代码. 

忸是，用例的 0 的不是说明你如何编 
写《序代码。你还得»外思考思考如 
何把 用洌里 的步*付诸为实 昧的行 
动。 

(®) : 假如用例并未帮我*写程 

序.那么什么是重点？为什么*花时 
间在用例上_? 

^: 用例确实有助于你编写《 

序.只是不特定于编《切节，例如， 
假如你不为 Todd 及 Gina 編写用例， 
你不会想到 Fido 可*会被《在外面. 
或者意识到狗门需要自动关闭，这* 
全都从用例的編写而来. 

记住，如果不 tt 让软件做客户*它做 
的事，你绝对无法 写出伟 大软件。用 
例帮助你想出这*事，于*.你已炫 
准备好«写《序来真正实现用例所描 
述的系仗. 
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按援兩例检 壺需求 

目前为止，你已经有： r * 初的一组潘求以及良好的用例.但 
现在你 必須问 过头看舂你的需求，确认它们涵签 r 系统必须 
做的毎•件亊.这是用例着力的 地方： 


Todd 及 Mwa 的桕门， te 本 2.0 
* 求列老 

1. 掏门孖 052 •强至少有 12 英寸离。 

2. 遥控 s 上 p , 布一个垵纽。笤门 a # 著的，按 
• F 相钮后 兵门, « n 是兵 簷的 . 相下拽饪培 
孖门。 


这 m.T)U.TodJS. <iina ip f 珥到 
的表…… 


…… S ( i 4« 们新釦*的 
狗 H #** 的搴 


i 一 S 柏门狨 打孖，若未袖共闭，它会6动兵 
闭。 


布什么遺漏了吗？ 


现在你需要仔细检査用例，看屙系统必须做的 
毎一件亊是否被此需求所涵盖。 


ToddAWwt ^» n , »辜2.0 
梅 net 的攀 

1 . Fldo 在叫,吵 ***«, 

2. Todd S Mm 咍 H Fido 在叫 , 

S.Todd S W*ia » T 孅《 8»ta , 

门打孖。 

5. Fido 坨出去， 

6. Fido 办它的擧。 

6.1 狗门 t 动 兵闭， 
ft 2 FMo 在 >*. 吵** 进采。 
6.3Todd«Wtia"ft»FWo 在叫 (*- 
次）。 

6.4 Todd 或 »lna M T 遒硿 B » 饪 • 

6.5 狗门打孖 (*-： fc ) „ 
ZFIdo®*. 班 n, 

霉 .鸚 
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收集需求 




削尖你的铝笔 

你的需求涵盖了每一件事吗？ 


1、'面左边是狗门所做唞 诂的 列表， ft 接来自干第78饵的用例.你的任务垃耘 
ui 出处理用例中毎个步明的 黹求， 并将耑求的编在用例步骤旁的空格中， 
假如用 例的步!保并不涫要你做任 Hit, iif'JN/A. 表示“没釘”。 


Todd 及 Gina 的狗门，版本 2.0 
狗门做的事 

1. Fido 在叫.吵着要出去。 

2. Todd 或 Gina 听到 Fido 在叫。 

3. Todd 或 Gina 按下遥控器按钮。 

4. 狗门打开。 

5. Fido 跑出去。 

6. Fido 办它的事。 

6.1 狗门自动关闭。 

6.2Rc)o 在叫.吵着要进来。 

6.3 Todd 或 Gina 听到 Fido 在叫 
(再一次）。 

6.4 Todd St Gina 按下遥控器按钮。 
6.5 狗门打开（再一次）。 

7. Rdo 回来.进门。 

8. 狗门自动关闭。 


iif 4我们布的三个*求.你芍以泠用 
奶的®个步瘭璉用》中 的保 —个’ 

TbddilfriHa 的揭门. 

* 求列老 

1. 掏门开19必桀至少有丨 2 英寸离。 

* n*ff 

:■后兵门 - 
•的， 技后孖门。 

，H 开. e 


一^^在5 个空格 41 S 下 
I . 2. 3或 H / A 。 


有没有找到任何用例步骒是你认为没有黹求处理到它 
的？若你认为需要增加额外的黹求，躭在下列空白处写 
下来： 



4 尖你的铝笔 

\ ‘蘚答 你的需求涵盖了 每一件 事吗？ 

下面左边是狗门所做 亊悄的 列表， 红接来 自干第78贝的用例.你的任务 
垃标识出处理用例中毎个 步骤的 龙求.并将潘求的编在用例步 W 旁的空格中。假 
如用例的步 骤并 不擗要你做任何事， 1- N / A . 表示••没有”》 


Todd 及 Gina 的狗门，版本 2.0 


狗门做的事 

1. Fhto 在叫，吵着要出去。 

2. Todd 或 Gina 听到 Rdo 在叫。 

3. Todd 或 Gina 按下遥控器按钮。 

4. 狗门打开。 

5. Fido 跑出去。 

6. Fido 办它的事。 

6.1 狗门自动关闭。 

6.2 Fido 在叫.吵着要进来。 

6.3 Todd 或 Gina 听到 Rdo 在叫 
(再一次） • 

6.4 Todd 或 Gina 按下遥控器按钮。 
6.5 狗门打开（再一次）。 

7. Fido 回来、进门。 

8. 狗门自动关闭。 




饬芍後含 在这1 故入 N / A . ® 妁 
i 他 们挖抬 a. *不4 伢 必獨让 
Jf 的…… fSJL . 240 KW . ® i 6 
控器.诂们砝铭軲 


' 夺时：？>!?•，《釦幵0的足”不 
对.愚砝出去的。 


t *. ¥湞珞枝在 


有没有找到任何用例步驟垃你认为没有盂求处理到它 
的？若你认为需要增加额外的耑求，躭在 F 列空白处骂 
下来： 

不，我们的 t 求涵籯？系统《供的苺一件 
摹。 我们准音好， 玎吆真 王編》«终 
^ t 求 af ° e ? 




收集霑求 


那么，我们现在能编写一些程序代码吗？ 

有了手上的用例与黹求.你已经池备好编写 Todd 及 Gina 会 
满意的程序代码了.检卉•下我们的擗求， 砑 fi 究& 要编 
写什么程序 代码： 


iii Oouf ioft 
4 人 8 tu 戌 



的.的 it ； 索求 
不**«何喵岑 


ii4 我们和.下 0 “ 

总 Qina {>) 论射鰣坩 
的 t 求……我们必嫌 
8*g« 璆代砝來*现 
tli * 关门这件搴. 


tbdd && ina 的枸门，眩本 2.0 
龙求列老 

1. 枸门孖 o 必頦至少«12英寸高。 

2. 遥控器上 R 布一个桉钮。 若门是 兵潘的 ，按 
■ F 桉钮后孖门,若门是孖*的. 按 T 按钮后 
共门。 

3. - S 构门拈打孖，若未拈兵闭，它会 fe 动共 
闭。 




f 劫兵狗门 

唯•需要编 w 程汴代码的就只有狗门打开后自动关 闭的需 
求。 ih 我 ( fllBl 头洱增加-咋处理 步®: 



public class Remote { 
private DogDoor door; 


*<8用?《« SP 乌 4 吋奇 
荚的典。 



public void pressButtonO { 

System.out.println<~Pressing the remote control button..."); 
if (door.isOpen()) { 

door . closeO ; - -〜遠硿|| 3 «< 5 枝存 代砝让淺构 n 任打 


door.openO; 

final Timer tim*r = new Timer(). 
timer. schedule (new TimarTask() { 
public void run。{ 
door.close(); ■ - .一 
timer. cancel() 


,* 个 t,w * ,T4s * 


1^) : 与 Timer 相关的材料是什 

么？能不能使用 Java 线程 （thread) 
来关狗门？ 

S S 然 T 以，使用 Thr«*d 来 
关》门绝对没问事实上，那正是 
Tim_r*« 的事： 启劝一个后台 
ThrMd, 然而 Tim«r 让求来执行任务 
时 tffS*. 因此对 R«mot •类而言 
似乎是个好选#. 
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| 什么将 timer 变置声明为 


B 为我们要在 Tin 
囲名类 (anonymous class) 中调用 timer 
的 cancel() 方法.（II如你 
要在 B 名类中访问外《类 
(enclosing class . 此例中为 
Remote) 的变量， 那* t 量必« 
是 final。 真的.这样才能正确运作。 


1^1 : 你为什么要调用 cancel()? 
运行 TimerTask 后 timer 不会自动退出 
吗？ 

^ : 它会的 . <8大 f RJVM * 
要很长的时间，才鼈从垃圾收集》收 
W Tim « r „ 这会速成《序无法*利 
退出.而在真正优 推地退 出之前，你 
的《 外 还得运行几个小时.这 T 不太 
好， <2 是主动调用 canc *10 能醉决 
这个问題。 



收集霜求 


我们熏 要新的模拟器 r 

我们的 III 模 拟器不洱那么有用它假设 Todd 与 Gina 手动关狗门， 而不 
是:让 定时器做这项1:作. 史新我 们的校拟器.好 it 它能与新的 R-»ot •龙 
一起;I： 作. 


0 

DogDoorSimulator.java 


public class DogDoorSimulator { 


(if 苗的* 
本《阉 . <sm 
下# a 含勿 a 狗 

nnD9iii¥!~ 


public static void main(String[] args) { 

DogDoor door = new DogDoorO; 

Remote remote = new Remote(door); 

System.out.println<"Fido barks to go outside..•">; 
remote. pressButton {); 



移的 rtPJ® * . 



System.out.println(''\nFido has gone outside ../”； 
remete.proccButtonO; — - - 

System.out.printlnJ^nFido's all done..."); 



沒戋由殉 n 中. 
7 # 下# a 吴狗 

On 

的- 


System.out.printlm 


: "\nFido’s back 


inside..."); 


iif « 名 _ 个刁蒯哚 《4 
代《的《*方. ftm-irtit 


: 你的 timer 程序代码把我 

弄糊涂了.能否再说明一下这里的霆 
点？ 

^ :好的.你不需要太执着于这 
里的 Java« 夺代码.重点是用例帝我 
们耳出良好的需求，而需求让想出如 
何写正螭运作的》门<1序 t 得容易„ 
这迖比如何（甚至以任何 i# 言） 苟出 
角门<1序代鴒史玄要. 


1^1 : 那么新的模拟器瀏试我们想 

到的主要路径.对吗？ 

^ : 没错 • IH® 茱78霣，1 
■9— 下狗门在做什么…… 坏是新 
DogDoorSimulator 测试的内容 ，我 
们*測试 Todd 及 Gina 的新狗门， * 
看它是 S •像 他们要 的筇样运作. 


: 为什么不测试我们找 a 的替 

换路径？ 

:问得好.我们 来测试 这个版 
本的約门，然后昇深入地谈_* …… 


当前位置 ► 83 





运作正 常 吗 +. 


a 试驱动， k 本 2.0 

该垃府苻我们的努力是否有回报的时 候丫. 来_»改 ft 过 
的新版狗门吧， 

O 将 Java 源代码编译成 .class 文件。 



DogDoorSimulator.java DogDoorSimulator.class 










运作 正 常 f 展示绐 Todd 鸟备 iMa 着 . 


收集需求 


顼在其实 
坚是里运 
作…… 



没错.替换路径与主要路 
径这两者都需要测试。 

假如亊怙秘次都运作得像你预期的那 
样.不是很 4 f 吗？当然，在真实肚界 
里，那几乎不会发生.在我们把新狗 n 
展示拾 ToddijGina 看之前， il ： 我们花点 
额外的时 M 来确认狗门在 Fido 办完取后 
却没冇冋来时也会运作 iK 常. 




……所％ 
要 为事幘 
里赞 的幘 
况进行规 
划与测试。 


- 

如何改变 DogDoorSimulator 类以测试 Fido 
K 时间* 在外面的情况？ 


你能为 Todd 及 Gina 的狗 f 1至少 pf 想出•种锌换路 
径吗？为你的新 W 换路砼骂个^例并!6新 Tfi 求列 
表. 







本®分 4 i * 路抆. 
isn -. 拳饵宠 含# 


重探 f 狳路径 


确认 -- K 我们典的知 ifi 衧换路径的内容，然后电新 


DogDoorSimulator 以测试新路彳令。这里是来0班68 (J (的主 
要路柃 R 1 ,伴随》我们之 fl ! f 想到灯•添加进用例的籽换 路泠： 


DFidO 在叫.吵着要出去 


® 狗门打开 
® Fido 跑出去 





收集需求 


@ Fido 在叫.吵着栗进来 


Todd 或 Gina 按. 
控器按钮 


Fido 办它的事 


： i4. 

•甙. 












收集涛求 



Fido start 
...so Gina 
Pressing t 
I The dog dc 


测试驱动，皈本 2.1 


sjava DogD 
Pido barks 
Pressing t 
rhe dog dc 


s Do 讲 oorSimulator 

barks to go outsi 
W islng the remote ca 
’■a dog door opens. 
Fido has gone outsid*.. 
Fido's all dona... 

Th« dog door closes. 
...but ha,a stuck outait 


nas gone outside... 
"s all done... 
dog door closes, 
it he’s stuck outside! 
starts barking... 






renioce control 
control button. 


sing the 
dog door 


s back inside, 
dog door close 


对 DogDoorSimul « tor . j * v •做些改变，然后*新编 if 你的测试 
类.现在，你已经准备好脚试用例中的籽换 路径： 





程序代码磁铁 
解答 


M 1这是我们完成的模拟器，确认你的答案跟我们一样。 


public class DogDoorSimulator { 

public static void main(String[] args) 
DogDoor door = new DogDoorO; 

Remote remote = new Remote (door); 



_J Systeimout ^^^^|(|) hJ |^ __ / 

. ^pres^pu^on^M)T7~W 〆 _ 

outside..." 

System.out.println("\nFido*s all done..."); 

try { _ 

Thread.currentThread().^_l^^fPllOOOO); 

} catch (InterruptedException e) {) 


(3 ■•应 * 的璉 

方加上 • 5 句；.分咢知 

耗咢。 


你 qttii 角 "5 -…0 

T 。" *，《 “加 um0U 

< S 4 抓气 






收集需求 




当事情按正常情况进行时 


4 ^ 


真锖癱鼸 一眞鶬 

本周 专访： 

认识快乐路径 (Happy Path ) 


Head First ： 主要路径先生，很髙兴你来到我们节目， 

快乐 路径： 事实上，我@欢大家叫我 ••快 乐路径 -• 我知道很多书叫我 ••主 要路袷”，但我发现大多败人能 
i 己得••快乐路径”。 

Head First ： 真不好意思。无论如何，很高兴你今天来到我们的节目，快乐路径先生，而且你也很守时。 
快乐 路径： 谢谢，我总是守时，这对我真的很重要 • 

Head First ： 真的吗？你从来不迟到？ 

快乐 路径： 是的，一次也没有，我也从来不会错过约会。我的字典里没有“犯错”与“出乎意料”这两个 
词……你真的可以放心地依靠我，毎一次都可以。 

Head First ： 那真是相当了不起的宣言. 

快乐路径 ：嗯.那正是我灵魂的一部分. 

Head First ： 那_正是你得到这个名字的原因吧？你总是乐于准时 R 不犯错。 

快乐 路径： 不全是，不过你说的虽不中亦不远矣！他们叫我 ••快 乐路径”，是闪为当你跟我 ft 时.都 

会如你所®地进行.当你行驶在“快乐路柃"上，没存亊怙会 出错。 

Head Fret : 抱歉。不过我还是有点惊讶，你的岡 IHM 的没卉事悄会出错？你确定你《的蛙活在真实世界 

里？ 

快乐路径 ：嗨. 別误会我……在真实世界里事情气然会出错。然而，3错误发生时，我会把唞情交给我的 4 T - 哥 
们， 替换路径， 

Head First : 喔，我想我现在明白了。事情会出错，但那是替换路径先生的工作， 

快乐 路径： 是的，差不多啦。不过，我不会太担心那种怙况.我的工作是照顾好例行工作，确保亊情像人们预 
期的那样运作。 

Head First : 挂，那一定很有成就感。 

Happy Path ： ■©. 大部分时间是的，但事情确实趋向干出错，似乎很难要求任何人自始至终都跟着我。#换 
路径通常会在某些点介入，但我们总是合作愉快，所以没什么大不了的。 

Head First ： 你会觉得替换路径先生老是爱打岔吗？我能想象你们之间好像有点关系紧张…… 

快乐路径 ：不. -点也不.我是说，我们的方向一致一 il : 客户实现自标 )1 ••确 保他们满意。•旦我们被定义堉 
铯.编巧吒川裎汴躭«的变得简单 r 很多. 

Head First ： if. 谢谢快乐路径先生。各位听众.这就垃我们今无节 M 的内容。下姑期. 我们将 Wft 找 W 换路 
袷先生来我们的 YiH , 让朋友们听听他的说法。住那之饷. W 大家尽 * 呆在快乐路袷 h , 但也 別忘了 为问明 fti 
作规划 I 



收集需求 




下面左边的是你在本章所学的新术语.右边的則是关 t 这些术 m 的意义与用法的描述•你 
的任务是将左边的术语与右边的语句进 行配对 汴将它们填写完辂。 


External 


后动用例 所描迷 的步骒列老，浚布它，用 
例是不会孖&的。 


系 统要成 功所必頻做到的事。 


Start 


让你知道两例何时轱東。没布它，用俐会永 
达链议7去。 


Requirement 


帮助你 《»«■* 求捋洋述系统®什么。 


Value 


当一«正常运作时系竑在戗的擧。通常是害 
户谈论系统对所描述的摹。 


Condition 

Path 


通常 是用例的笫一步。 

设«它，用例对用户 轼浚布价值： 设布它， 
用例遴常会失败。 



在泣的**术诏料 不*® . 你珥迻 用在迖 
的4义耷 CK 的科 E 成入术 , •番的 澶.屬®分 1 
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1 % ♦ 连迻焉？ 


F 而左边的是你在本章所学的新术语，右边的則是关 T - 这些术语的意义与用法的描述.你 
的任务是将左边的术语与右边的语句进行配对并将它们填写完整。 


External 紐 atcn _^ 启动用例所描迷的步骒列表， 没有它 ，用 

例是不会孖飽的。 





系统 要成 功所必頜戗到的事。 

让你知道用例何时姑柬。设 布它， 用俐会永 
迗结成 T *。 

帮助你收» 好* 求#详述系统做 计么。 

S —《正常运作时系 法在做 的擧。通常是窖 
户谈论系统时所描述的擧。 

通常是用例的笫一步。 

设 布它， 用例对用户弒 浚布价 值；浚 有它， 
用例通 常会失败。 


►译注5:对于 *3 項与 SU 喟的答案，你或许会认为是 -StaitPoini •与 “Slop Poim” ，其 
实也无妨，事实上， "StartCondition* ^ •SlopCondilion" 两个 iflJL 到 Jt 100 If 
才会出现. 
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用例大惊喜 




你的铝笔 

解答 


是再写一些用例的时候了。 

下面坫2位对 ••超 》狗 n ” 感兴趣的潜在客户。你的 ( t 务是为毎 
一位客户写一个用例来解决他（地）的问题。 




收集黑求 


J 竣坊在叫.我格本 \ 

«不;驀*它*««出*,你能设 it ^ 
-个鸚 n , 金在 e « 浓孑抓 n 时《打 


这费* 彖实杉 
出现在 Hell ! (的 

at . «** 

你 *»•« 过玷 
的系 恍金 s •等 
iiftrt . 你在 


Holly 和 Pruce 的构门 

1. Pruce 抓狗门。 

2. 狗门打孖。 

3. 长 ruce 出去。 

4. 狗门 I )动 兵闭。 

5. Pruce 办它的擧。 

6. Pruce 爯次抓构门《 

7狗门爯次打孖。 

8 . Pruce 进来。 

9. 狗门 t 动兵闭。 


我们*的 #* 多_魚作总嫜祐 
s 出这个用利 .卷 來靠 ** 

外的闭 

John 和 Tex 的狗门 

(认某种方式）狗门打 
孖。 

2. Tex 出去。 

3 . 狗门 t 劫兵闭。 


I 


和 < i ) o “ 说 T tt (i t-tfim 
•效兮兮 w. fs(6nn^ ia 
rt ••••••®*fc. ciA 的 i"i ■痴 

路《。 


4. Tex 办它的事。 

冬1 Tex # 得脏兮兮的。 

4.2 Jobi 拕 Tex 清理子净。 

5. John 摊 T 嫌钮。 

6. 构门打开。 

Z Tex 雄来。 

%. 狗门 t 动兵闭。 



用例的三要索 


0 


煲多用例磁铁 

还记得用例的•:个郎分吗？该是把你所乍的功夫拿来用 
的时候了*在这儿页，你会肴到一些 用例. 你的任务坻 
将«闹底部的坫个磁铁放入 ffl 例的相应位 



Holly 和 Pruce 的狗门 

Pruce 抓狗门，砂碁要出去。狗门打孖， 
Pruce 出去，狗门在预设时间后自动兵闭。 
Pruce 上完涵所，接荔爯一次抓狗门。构门自 
动打孖， Pruce 矽来，然后构门 I )动兵闭。 

假如 Pruce 抓狗门，侄是没布进出（杲在象 


ft 9 w e © * 74 5 j 
3 这螌内容 


- - - ----- 

你*言在 找沒科 么问廷 * 

你* ® S . 麵《 « * ， . 
f * 几个¥籌的用奶辂式 


里或外 ®) ,它玎认爯次抓构门来重斩打孖 


狗门（从宗里或外 ®) 。 


Kristen 和 Pitsie 的狗门 

1. Kristen 在小型鍵盘上输入代码。 

2. 狗门鸟屋沟所有的窗户狨锬上。 



泛神《技凍: i 用 




收集需求 


John 和 Tex 的狗 H 


主要参 鸟者 ： Tex 

主要 路径： 

次要参 鸟者 ： John 

1. Tex 出去。 

前 I 条件： 狗门敏孖， 

2.梅门 f > 动兵闭。 

Tex 能够出去。 

5. Tex 办它的事。 


4. John 按 T 按钮。 

目标： Tex 上完躕所， ® 來， 

5狗门打孖。 

浚把屋孑#脏。 

6. Tex 进来。 


Z 构门 t 动兵闭。 


扩展 路径： 


4.1 Tex # 得脏兮兮的。 


4.2 John 挖 tfex 清理子净。 


ii 样的磁铗蒋出 
用制 的终魚（终 



FWofitt 代表用 
剩栌外郝《 *6 





更多用例磁铁解答 


还 U 1 得用例的飞个邢分吗？该足把你所学的功火拿来的 
时候 J \ 在这几 W , 你会看到一些用例，你的任务垃将豇 
面底邢 的毎个 磁铁放入用例的相应位 E ， 


Hollv 和 gruce 的构门 

舶打孖. 

长 ruce 出去，狗门在预设对问后自动兵闭。 
Pruce 上完涵所，揸荔爯—次抓构门。狗门舍 
动打孖， Pruce 铵來，然后构门龟动兵闭。 

_假如多 ruce 抓狗门， （2 是没笮进出（呆在象 
_^或外 ®> ,它玎认苒次抓构门来重斩打开 
狗门（从宗里或外面> 。 


条件 (stop coniitio ") „ 
银釦有》 玷梦痴珞柃. 
它 ；i 當不&蕞后一句 


g PruceST 认出去上 
^颇所，无索 Holly 孖兵 
狗门（甚1不索要咁 
到它 叫）。 


用倒 w 畎场价碘（在十多 
坻格式 f > ； a » t « vH 5 ffi 
例 i. 田 螫 

戌出皐 




» Kristen 的允许 Wtsie 不 

出去。 


^feristifcp gjtsie ^ ^ n _ 

■ilCris 恐在小型鍵盘上输入代码。 
么构门与屋沟所有的窗户 

_ 


终 i 条 碑 几呼运4用 
的* 后一个步*, 



收集需求 



当 * 位轚 ► 101 



削尖你的铝笔 


用例的真正威力是什么？ 


你已经玢过用例怎样协助你 «!* 完整的耑求列丧。 T 面坫》•咋要仵石•的 HI 例。 
你的任务垃判断川例旁的龙求列衣 娃办涵 ,!£ /* 毎•件事。 


Kristen 和 gitsie 的揭门 _ 

lXristew 在小型鍵盘上输入代铒。 
2.狗门鸟屋沟所布的窗户狨锬上。 


这 4 K>ist<» Ho Bitri* 

的狗 n #* 列表 。刺 
<5«何寧渣《5线不4蟄 
；如梁 fi , S 下你认 
的狗 Of * 处瑾的 《外* 



ais ( j 5 K « ut «" 

Ha 8itsi« ' 


Kristen 和 gitsie 的狗 
~~ 索求列表 

1. 小型鍵盘必绍接受 4 伎数的代 
码。 

2 - 小型鍵盘必绍能够锬上狗门。 



收集需求 



荟*在* 104 S 。 


当前位置》 103 



尖你的铝 f - 


蘚答 


用例的真正威力是什么？ 


在下 面的每种情 况中.用例描述狗门应该怎样运作，恨黹求不完整，这电垃我们 
根据 m 例所肴到的擗求列衣中漏掉的一些亊. 


Kristen 和 Pitsie 的狗门 _ 

用例 

IKristew 在小型鍵盘上输入代码。 
2.狗门鸟屋沟所布的窗户钺锬上。 


这一龙 有魚笱 rt. 用 
例未 44A«MBiui«(t 
0的《仞辜，@此搴* 
t . 角例耷 **»•)«■« 
不**. 

J 6«<50« fHS . ^ 
g« 含不 



_ Kristen 和 gitsie 的狗 n 

~~ i 求列表 ~~~ 

1 . 小型鍵盘必绍揸受 4 忮数的代码。 

2. 小型鍵盘必领能够锬上狗门鸟所 

“户 。 ^ 

茨小型鍵盘必桀能够为狗门乌屋沟 
的所布窗户孖锬。 


■a， *»«5 (残不劣餐 
W) 用例 itttWW* 求,. 


尚赛保 ■£• 购门 t 
新_’二 


收集需求 


Holly 和 Pruce 的狗门 
用例 

Uruce 抓构门。 

2.构门打孖。 
i&njce 出去。 

4.狗门 t 动兵闭。 

5 多 roce 办它的事。 

6 .Pruce 再次抓 狗门。 

Z 狗门爯次打孖。 

1 霣 nice 逬來。 



9 .构门 I ) 动兵闭。 _ 

_ Holly 和 Prt/ce 的狗门 

t 求列表 

1•狗门必颔能够採谢到构在抓门。 

2•狗门应该能体箱令打孖（依梅步 
骤 1) 。 

多•狗门应该 t 动兵闭。 
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00 A 邛 i 爯箱 

OOA & D 完全关系到编伟大软件.没有确认你的应用程 
所做的正是客户所要的是无法实现的， 


在这一章 4 i . 你学会了 -些工具，确保 在展示 你所途的系统时客 
户会笑得合+拢嘴.这里是一些要经常使用的 工具： 


乘求 


好的 t 求砝係你的系统如客户预期 
的坪祥注 <1。 

认 t 求浴霣3 $统的鰣<5用例.' 
注用用 W 找出客户忘5 苦柝 饬的 

寧 

用制将 戏*«何不宪 t . a .# 的 t 
求. 伢 g«*l 坍它们加利你的系 
绝中。 


00基础一 


00涿則 


在41 下來的久 
a . a 们含 
在 ii * 个分 ft 
aio 中加 i. 
霞多 i #»。 

； H> 


要点 

■ 需求足系统为了正确运作所必 
须耍做的水. 

■ 最初的黹求通常来自客户. 

■ 为了确保你有一组好需求，你 
应该开发出系统的用例。 

■ 用例洋述系统应该做什么。 

■ —个用例具有单一的目标，但 
内含多重路径以达到此 目标。 

■ 好的用例具:有起始与终止条 
件、外部启动者，并 a 对用户 
而言有明确的价值。 

■ —个用例躭 a — 个系统如何运 
作的故亊。 

■ 对于系统要完成的每•个自 
标，你至少会有 -- 个用例， 

■ 在用例完成后，你可通过它格 
炼并增加你的需求， 

■ 确保所有用例皆可行的需求列 
表是一 组好的需求。 

■ 你的系统必须运作在真实世界 
里，而不只是在你預期的情况 
中. 

■ 当事情出错时，你必须有替换 
路径达到系统的 H 标. 


106 第2章 


• ■: H . 《深入浅出议4携式》的这着食*分类很 热悉. 
邳4 ® 的 ooa & o 岛 ilv +« 式 g 4孕奪导一鼇命前«。 



00 A 邛垠字游戏 


收集需求 



横排提示 


4. The moin path is sometimes called the 
_path 

5. A use case must have this (Two wards) to 


10. In the dog door system, who wi 
external initiator? 

13. Use coses focus on a_ 


14. When Fido is here, the dog door has hit its 
stop condition. 

16. A use case is just a list of things that a 

18. A use case tells a_about How a 

system works. 

21. Use cases are easeist to understand when 
they're in this kind of language. 

22. Good use cases make for_ 


24. A use cast helps you understand how o 

syitem will be_ 

25. Use cases help you gather_ 


竖棑提示 


1. A use cose details how o system_ 

with users op other systems. 

2. When Things go right, you're on this. 

3. Use coses are all about the "_■ of your 


6. Without use cases, you won't know if your 

requirements ore . 

7. If you have four goals in a system, you'll 
hove at least this many use cases. 

9. Sood systems work in the_ 

11. Fido docs this to signal the start of the dog 
door system's use ccse. 

12. When things go wrong, you end up on an 


_ path. 

15. Fido isn't part of this, but his dog door is. 
J7. This is whot you should do to the customer 
to gather an initial set of requirements. 


19. How many use cases are there in Todd and 
Gina's dog door? 

20. Fido was chasing these when he got stuck 
outside. 

23. A requirement documents this many needs. 


当前位鷲 
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习 颶解答 



程序 代码磁 铁解答 

DogDoor 类已经完成，因此你现在黹要做的事垃为遥控器笱- 
个类.我们已经在下面起了个头，不过你的任务是完成它■■使 
用贝面底部的程序代码磁铁完成 Remote 类的程序代码. 


注意，你珂能+需要用到所有的 磁铁。 


public class Remote { 

private ______ door; 

public Remote( _ 

this.door = door; 


public void pressButtonO { 
















你是英雄 r 


热情的岛屿.«蓝的海洋.白净的沙滩.你正 ft 享受这-切，还 
有大把大把*进沐 裤的饯 。啊，这才是程序设 II •师的生活！这垃 
你刚让 Doug 的 拌狗 门”在市场上成功出 * 所获得的报酬。你 
为 Todd 和 Gina 所达的狗门非常成功，现在 Doug 正将它销拾全世界 
的客户 • 

o 0 “*2 用你栌 
存嫌 "5 大*九龙. 

的枝* — 


侄狻筹采？个电活 




來 1-S00-99S-99SS 



你 ：哦， 有问埋呜? 

Todd 和 Gina : 没有，没有，那个狗 fl 就像你所说的那样在运作。 
你：一定是有什么问题吧？门关得不够快？遥控器按钮怪怪的？ 
Todd 和 Gina : 没有，没有，真的没有。它一直运作得跟你安装 
并展示的那天一样好《 

你： 还是 FklojT 也不叫若要出去？你冇没有检迕 一 K 遥控器的电 
池？ 

Todd 和 Gina : 没有.没柯，我们发蜇真的没冇。那狗门太拌了， 
我们 H 是有些关于变9£的想法，想®麻烦你…… 

你： 嗯，如*件唞常运作，那 H 题到底足什么？ 
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需求变更 



客户永远是对的 


设到计划阶段 

该是再次格 ITTodd 和 Gina 的狗门的时候了.我们黹 
要想个方式，使得无论何时 Fido 在叫都能开门•咱 
们躭从这里开始吧…… 



- 

你刚_发现了软件分析与议计的一项不变的 K 理， 
你想想赴什么？ 





嚣求变更 


软件分析乌设计的不変真理 

好，在编写软件过程中一件总是不难预料的事情是什么？ 

+论你/|•:囑甩 r . 作._构让什么成者用什么编 Wi/i 卉，什么垃 1 彡你常相*右的一项不变的 rtffl ? 


无论你把应用程序设计得多好，应用程序总会是随着时间而成长或改 
变。你会发现问題有新的解法.编程语言会演进或者亲爱的客户会想出 
疯《的新需求，强迫你“ 修改” 运作屮的应用程序。 

制尖你的鉛笔 潘求时 时在变 ……有 B + ft 项 B 中间，有时 
在你认为 - wwii 完成时。写下你 h 前1卜: 
在使用的应用程序屮黹求吋能改变 的…咚 
理由， 


我的* >涹4让6用《9以不方式注<1: 


*的 老扳认 6戧的在用以 w «6 在用的方式含比*®在用《存的 
古式 <5。 


霈求 各秀杳 

假扣有很弁 
的芹例，侪 
強第觯佚谜 

适些新霈求。 


* a ' 如* «w<a 《深 入沒出 <4v+ 癢式> . a 
丰 S(VJ«<* 的铨《. ■I'js" 他0的» 法. pm ~ 

魚嘗雀 U。 射 由. 6 , thO . B „ c ^ 


当«位《 ► 115 




m 


iJ 

V /： V ； vV；.' J :: 






解答 


Doug 发明了能识别狗叫谇的硬件，你得想出怎样在狗门系统中使用 
他的新硬件。 

这 m 足我们解决 Todd 和 Gina 的问題以及实现叫 m 只別器的狗 fl 的 
方式，你是否也对此 R)» 似的》改。 



a. WWOW 开， 
3 [ 


® Todd 和 Gina 听到 Fido 的叫声 
® Todd 或 Gina 按下通控器按钮 


我们*1>6夠门- 
坩加一个惰 
狗遠的 -I 声 


此 ffi 大郝分 ® 轉不 

t .••••• 

个《外的 歩瘃。 


y 叫声 

/ (^1 叫声 识别器 送出请 

I / f 求铪 狗门以打开狗 

a * V ttf 象*搞珞 


I 声识别器送出请 
i 給》门以打开狗 

» (•“ 6 -咐） SI 考乘 
a* If 減珞《上。 





需求变更 
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该走 _ 一条路径？ 



现在. 

扣唼味 3 也笮 3 


现 <5. » - 

3的 笮減块 


可迭 ( optional ) 路径？ 
f 换 ( alternate ) 路径？ 
3能分得清？ 


Todd 和识 Ha 的狗门， 瞄本么 1 
^狗门要傲的搴~~ 
l.Fido 在叫，吵著要出去。 

Ztbdd 成 Wwa 咁到 Fldo 在叫。 

2.1 叫声识别器“咁见”叫声。 

3. Todd 或 Wna 按7逞控器按钮。 

3.1 叫声识别器送出锖求绐狗门认打开构门。 

4. 构门打孖。 

RFido 路出去。 

6 .Fido 办它的擧。 

6.1 构门 t 动兵闭。 

6.2 Fido 在叫，砂畚要进来。 

6.3 Todd 或 Wwa 咁到 Fldo 在叫（再一次> 

巧 6.3.1 叫声识别器“咁见”叫声（再一次）。 

6.4 Todd 或 Wna 按 r 通控器垵钮。 

S 64.1 叫声轵别器送出清求绐构门 UC 打孖狗门 
6.5 狗门打开（爯一次 ） q 
ZFIdo ® 来.进门。 

8.狗门6动兵闭。 




肅 


V 


孑步*.任它 
Msaa 用例洗* 0 


这费 孑孕痒摄供― 
afe ^ a 楗的銶外 


■ ••… ** ii » 个子梦 
»* B _ t 44 供* t 
-不 》 的路 《 aa 用 

«T "- 

:这里的*«是：少《2与少 
*3 会因为少 *2.1 及步《 
3.1 的发生而不发生 . 《 
是.歩《6是必定会发生 
的.不会因步 *6.1 —步 
朦 6.5 而有所改变. 
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S 求变更 



6. Fido 办它的畢。 

6.1 狗门 t 动 关闭。 


3*eJ^ 

fS6.3.lTsS 



6.2 Fido 在叫，砂碁要进采。 

__ _ 6.3 Todd 或 & ina°ft 到 Fido 在叫（再一次）。 

.- - 3— 6. J .1 叫声识别器“咁见”叫声（再一次）。 

— 64 tbdd§Uina 按7遥控器按钮。 

- 64.1 叫声 识别器 送出请求绐构 n 认打孖构门。 
6.5 狗门打开（再_ 次）。 

ZFido ® 采，进门。 

氣狗门 t 动兵闭。 


121 







以你想要的方式写用例 


用例对堡而言必頻含理 

假如用例 it 你*到闲惑，那躭重写吧。有许许多多的方式编写用如，但 
® 点是，对你，你的团队以及你要向他 (fl 解释的人而言它必须合理 。因 
此，让我们重¥第121页的用例，让它们不那么令 人感到 困惑。 


£?****'» 





好主意！ 

主要路径应该是你大部分时间想要遵循的路 
径，因为 Todd 和 Gina 可能想要叫声识別器 
处理比遥控器做的更多的工作，让我们将这 
些步猓放在主要路径 里吧： 

Todd 和 frina 的狗门，版本2.多 


*66 谗齊 
<?.?_) 8 栌荦痒 i 
现巧中. 
*T4 劳淖珞衿 


构门要傲的搴 

本穽路技 

1. FW 0 在叫,吻着*出*。 

2. 叫声识别器“咁见”叫声。 
a 叫声识别器送出谙求绐狗门认打孖 

构门。 

4■.构门打开。 

SFIdo 铊出去。 

6 .Fldo 办它的擧。 

6.1 神门6动兵》。 

6.2 Fido 在叫,砂蚤要逬采。 

6.3 叫声识别器“咁见”叫声（再 
一一次）。 

^.6.4 叫声识别器送出请求绐鞫门认 
打孖构门。 


替換路径 

2.1 ToddsUina 咁到 Fido 在叫。 

$\ Todd ft &ina 按 T 遥控 S 拽钮。 

1 ? 

To < w 或屮 》* 大部分 时 用； Tf 4 用 
因此读 AMd 硿 8 的 

，稼 ± 现 

l \ 

6.5.1 Todd A (MnaWr 到 Fido 在叫（苒 

-次 ） o 

6.4.1 Todd 或 &ina 按 "F 遥控盎椬钮。 


6.5 构门打 ft (爯一次）。 
ZFido® 来.进门。 

8.狗门 t 动其闭。 
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从孖绐到 完成： 单一场景 

借符新 用例中的袢换路径，有不同的方式让 Fido 出去 h 圈所， 
然后再回来 • 这®垃用例中的-个特定 路径： 


Todd 乌识财的猗门， 
构门要戗的搴 


主要路枝 

*1^2 l.Rdo 在叫，沙着要出去„__ 

达个用 2.叫声 识别器 “咁 a ” 叫声。 


替换踣径 


的珞《 

部■歩 
琢‘«谂。 


a 叫声识别器送出谙求给狗门 认打孖 
狗门。 


2.1 Todd sj &ina 嘈到 Fido 在叫。 

3.1 Todd sS & ina 按 T 通垃器按钮。 


4 .狗门打孖。 • 
5 Fido ?6 出去。 
RFido 办它的拳 


6.1 狗门 fc 动兵闭。 

6.2 Fido 在叫.砂着 * 进采。 

6_3叫声识别路“。斤见”叫声 


-次）， 

64叫声识别 g 送出清求给构门认 
打孖构门。 

6.5 狗门打开（苒一次）。 

ZFido ® 采.进门。 

8.狗门 t 动兵闭。 


我们錡4过这1的芍洼 

_ ( optiaiul ) 孑路枝,.旮这 

种 rt * 下. Fi ^«4< Sft « l - 

_ * 6.3.1 Todd H. WMa°ft 到 Fido 在叫 

^ (爯一次）。 

(苒 , 


64.1 Todd s $ &iHa 按 "F 通拉器按 

a . 


爯 _次让 ToW 和 Qi »« 4 @ 
滅 ji 径中以 a 控 84 ian 
的打孖。 


戧们* J « itfc 
t 籌珞 fi . 让 
To<W 和 Qimi UA s 


a # ii « « * 食汾饬••条邊 a 诹例 \ 
的鞾 4 路技. 样 的珞枝 魷坊妗 
< i ，^7，« M « io ) 在擎一 用例中 a 
常笱一 « g « 的译睪 


-往含薄 8 
绍乘. ar,j 0 ^ a 

家 f 
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霈求变更 

% 


: 我理解用例的主*路径. 

你能再解释一下替换路径是什么吗？ 

: 鸶换路径是&含在用 W 

中的一个或多个少* . 这* 步骤是 
可选的 ( optional ) 或提供螫换性的 
( alternate ) 方式通过用例。替换路 
径可能是增加到主*路径中的额外步 
驟.或提供步骤让你以完全不同于主 
要路径的方式到达用例的目的地， 

I ®): 所以 . Fido 出门并被锁在 

外面的情况也是替换路 径的一 部分. 
是吗？ 

^ : 没《.在用例中.步 

*6.1. 6.2. 6.3. 6.4 和 6.5 是替换路 
径（译注2> . 这《是系《■可能通过 
的頦卟 少*.只有在？比0被«在外 
面的情况下才需*„然而这是替换 
路径.因为 Fido 并祚总是被《在外 
面——系统•从步 *6 直接前进到步 
*7. 

: 我们为此使用子步骤编 

号.如 6.1 与 6.2? 

^ : 正确，因为有《» 卜步骤 

的替换路径只是一纽用《主 要路椏 
以外的 頦外少 《.. #?!(10被《在 
外4时，主 ♦路 技少*是6与7, 
0此 替换路 径步*从 6.1 开始. 
— J .11 6.5, 它们是步《(■的可选 
( optional ) 部分. 


I ®): 那么.当你有两个不同路 

径通过用例的 同一部 分时.你称它为 
什么？ 

^: %. 夢实 上嗶只是另一 

种替換路径.畜 Fido 叫时. 有一条 
路径涉及到 Todd 和 Gina 听到 Fido 
叫并开门，而另一条路径涉及到叫声 
识别器听到叫声并 开门。 但系统祓设 
计成不是由遥控器开门就是由叫声识 
别器开门，而不是两者同时可以， 


(®) : 你可以在相同用例 里有一 

个以上的瞽换路径哄？ 

^ : S 然.你可以有多条替族 

路後提供额卟的，* . 以及多个方式 
从起始条件 (slartcondition) 通往终 
止条件 （stop condition >。你甚至可 
以由替換路径早一点终止用例……不 
过我们不需要任何把 Todd 和 Gina 的 
狗门弄得很复杂的事. 


夕笫—歩到最厉—步拯 
过芹例的宾檠脒椏挤为 

岭。 

大梆穸的芹倒有—些> 
同的场景，徂昱是有扣 


的可4少朦 （(MH6.I 到 6.5) 也* 替换路 K. 
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替换路径 S 可选的 



真锖集象 一纖儀 

本周 专访： 

替换路径的真心话 


Head First : 你好， tf 换路柃先生.听说你最近心情不太好，说说肴，蛙怎么 
回亊？ 

替换 路径： 设有啦，只足冇时觉得不足很受 t 视.我是说，没有我你很难组成 
一个像样的用例，但我好像还是常常被 忽视。 

Head First ： 被 忽视？ 但你刚才说你几乎是每个用例的一部分，听起来你实际上 
应该很 甫要。 

替换 路径： 就是啊，听起来可能是那样。然而，即使我是用例的一部分，也可 
能因为其他一组步骤而被跳过。真是让人不舒服……就好像我根本不存在一样！ 
Head First ： 你能举个例子吗？ 

替换 路径： 就在几天前，我是一间新的 M 店 “Musicolog” 的构买 CD 的用例的 
.部分，我本来很兴奋……结果，我负贵的是客户倍用卡被枳绝的情况。 

Head First : 嗯，听起来是个蛮乘要的工作！有什么问理吗？ 

替换路 径：嗯 ，坫啊，我想它是很讯要， m 我总坫被跳过。4/像坫个人在1了 
购 CD 时他们的倌用卡全都被接受. Bp 使我是用例的.部分，也不垃烺常见的场 
坟的那个部分。 

Head First : 啊，我惮了，除北某人的佶用•被拒绝，开则你不会被涉及到。 
替换 路径： 没错！内务和安全部门的 人都戽 欢我，他们总是.冉说我对公司有 
多重要，但有谁想坐在那里整 H 无所事亊？ 

Head First ： 我知道是什么情况了，不过，你还是在帮忙处理用例’不是吗？即 
使你不是总被用到，但有时一定也会被请求到吧。 

替换 路径： 这倒是真的，我们全都是为了相同的目标。我只是不明白，我对用 
例那么重要，却还是那么少被注意到， 

Head First : 嗯，只要这么想……用例没有你就不完整。 

替换 路径： 是啊，步 奶.1 与 4 .1 也一直这么跟我说。当然 • 它们是客户在系统 
里已经冇账号的情况下的袢换路径，因此它们总是会被用到，也就可以说得那么 
轻 松了， 

Head First ： 別气馁， 籽换路 柃先生 • 我们郎明白 你娃用 例中®要的一■部分 • 





m 求变更 


4 尖你的铝 I 

在 Todd 和 Gina 的用例中有多少个场景？ 

冇多少不间方式可以通过 Todd 和 Gina 的用例？记住，有时你必须采取多条种换路 
裕屮的一条，柯时你必须完全略过袢换路柃。 





4 尖你的铝？ 
、、解答 


在 Todd 与 Gina 的用例中有多少的场最？ 

苻多少+同方式 -T 以通过 Todd 和 Gina 的用例？ id 住，有 B_) •你必 


须采取多条#换路径中的-条.时你必須完全略过袢换路径。 







准备写程序代码吒 


需求变更 


既然我们的用例己经完成.并且想过了狗门的所有可能的场最.我们就准备要编写程序 
代码来处理 Todd 和 Gina 的新 需求。 让我们想一想*要做什么…… 
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扩充需求列表 

完成 f 求列表 

81此，我们需 S 通过在需求列表中增加两个额外的需求来处理两个新 
的袢换路柃 • 我们已经 ST . 划掉我们的黹求中已经处理过的步*，而 
看来会/ 1 *我们甫 轚在黹 求列表屮增加额外的擗求， 

Todd 和抑 > a 的聆门， 

费门累徼的擧 


这1*的«»个 


主 g 路径 
- tRdogvq . 1 


g _ 嫌路枝 


2 •叫 声识别 S 叫声。 

裹叫声轵别 S 送出锖求狳鸚门《■打开 
狗门。 


3.1 TbiM a O i wa 技卜 &} 21 S 7 ! m 7 *rn 




6. J 叫声 -" fta " 叫声（異 

。 

64叫声识别 S 送出珀求》»门认 
打孖桕 n 。 

6 . 5 WH 打 ff (B - 吹 ) - 


孑 r i du ® 耒 . anr 


记 (i . a#4 
砮 赛每兮 中的铁 
f . U -* 用 


…… 搿以我 (0 

#*# 


(2 f 4 S 个 1 加入列 
表的 **.. 


Ibdd 和炽 wa 的裨门， K 本 2 J 
, t 求刊表 

1. 构门孖 wl 少要布 12 英寸高。 

2•埵控 g 上个按钮。苕门是 其著的，按 
T 椬 a 后孖门,若门是孖 潘的， 按 T 拽钮后 
兵门。 

a _® 构门打孖，若未狨兵闭.它会6动兵闭。 
+叫声识别 s 必涵能识別出狗 在叫。 

5« ftW 狗叫时叫声轵别器必猱打孖夠门。 
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霑求变更 


规在 ,我们玎认爯次孖飽为 
狗门编写程序代码 

新的程序代码伴随荇新的需求 ifli 来。我们潘要-咚叫 
声.能 m 听叫声的叫声 w 別器以及能打开的狗 n。 




f：r •用呔变 
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那是我咁到的“狗叫声”喝？ 

当 Doug 的硬件 “ 听到- 狗的叫声时.我们*要运行某种软 
件.让我 ( fl 创达•个 B « r kR * CO g n i Mr >) S 汴编写我们能用来 
响应叫声的 方法： 


Q 

BarkRecognizer.java 


public class BarkRecogniz« 
private DogDoor door; -■ 


我 叫磨识奋的拘 0(? 甸 
奋 中. 


loor) { 


必汤 它埒 

*—^ n o 


public BarkRecognizer(DogDoor dooi 
this.door = door; 

> ，产 -- 

public void recognize(String bark) J 

System.out.println('' BarkRecognizer: Heard a + 
bark + f 

door.openO; 我们搿 f 电栌 u . 


，凳 问咚 匈題 


% 

| p | : 就 这样？ 看起来 BarkRecognizer 真的没 
做太多事。 

^: 现在它是没有。因为需求很单地 

—— S 狗叫时，开门，所以你的《序代码也很 
«拳.任何时候硬件听到叫声.就调用我 fl 的新 
BarkRacognizar 类中的 racogniz*(). 接着打 
开》门.记住，尽可能让事情«单；若非必要，就 


1®) : 假如不是 Fido 而是其他典在叫.会发生 
什么事？打开狗门前， BarkRecognizer 难道不应 
该确认叫的是 Fido 吗？ 

: 很有意思的问題！ BarkR * cogniz*r 会 

听到所有的叫声.佴我们不想随便为一只供狗开 
门.对•马？我们稍后可 能会® 头修正这个问题.在 
我们 进行測 试时，你也许 T 以多考 虑考* 这个问 




需求变更 



首先，确认_下我们是否考虑了 
Todd 和 Gina 的新 需求： 


个戍 
在我们芍以使用 
携扣 • 8铪这 M 8 
邁出 -) 声.《后 
刑试 一下* 们系 
的炊 4- 


Todd 和 Wna 的箱 n , te 本 2 J 
t 求列表 

1 .构 n 开 OS 少 s 笮 12 英寸;8。 

2 •遥控器上51布一个拽 a 。 若门是兵著的 ，垵 
• F 垵钮后孖门,若门 JI 孖麕的. 按 " F 桉炷后兵 
门。 

3.- S 构门打孖，若丰拈兵闭.它会 t 动兵闭。 
4•叫声 ffi 别器必頦能识别狗的叫声。 


5»6到狗叫时叫声识别器必兔打开狗门。 


T 


枝璆代® ……识到 巍 ……兴们的—声斿 未右正 ■•供 

8_ H 叫声的<4勿^- ^ 的嶂：它 

㈣ 0 。 ftf) ㈣ 个问也 
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启动新狗门 

用例.需求列表及程序代码全郎就绪， Lb 我们看看一切坫否按部躭班地 
进行， 

❶更新 DogDoorSimulator 源 代码： 

public class DogDoorSimulator { 


0 

DogDoorSimulator.java 


的 *4. ® 
it p . 4 * ^ 
遠件一 an 声 


public static void main(String[] args) { 

DogDoor door = new DogDoorO; 

BarkRecognizer recognizer = new BarkRecognizer(door); 
Remote remote = new Remote (door); _ 

► // Simulate the hardware hearing a bark 
System.out.println(~Fido starts barking . ,/ )； 
recognizer, recognize (''Woof"); ^ --- 

System.out.println(''\nFido has gone outside..."); 

System.out.println(''\nFido r s all done.""); 


一拓它 1 戏«构门. 
it 它妗峭狗 

- 

6aT^Rect75n[2«t 


try { 

Thread. ourrentThreadO. sleep(lOOOO); 

广 )catch (InterruptedException e) ) I 

iil * 拉 

筹碲 —& System.out.println("...but he’s stuck outside!"); 

// Simulate the hardware hearing a bark again 
System.out.println(~Fido starts barking .")； 
recognizer, recognize ("Woof w >; 


班 诔进«， 


System.out.println(''\nFido , s back inside..."); 

Hi . ( a -*- 

loii #0 C > ,M 宪含沒接 
a 控 8 铭 a' 


* iiz . 本丰的老 fi 的声 wa 
««« 人 »蟄 枋沒 有人金 
花 299.95 * 光英 一本丰 .， 伐 


O 重新将你的 Java 源代码编译成类。 


需求： ■ 



O 运行程序.看看无人照看的狗门开始行动。 


神 a 去 

5 . fiio 2 
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答案与打开的狗门 



在新版本的狗门里狗门没有自动关闭！ 


Rfii 足在 Todd 和 Gina 按下遥控器按钮的 
场》甩运行的程序 代码： 









需求变更 


但是在 BarkR«cogni*«r 中，我们开门了， 
却未关门， 



BarkRecognizer.java 
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重复程序代码 . a ： : 


我认为 Poug 的主纛太进7 i 我 
才不*在 a « a 乌叫声《别》中 
故入相 s 的《序 代码。 



重复程序代码是个坏主意。 
然而，关闭狗门的程序代码 
应该在哪里？ 


». 共门*»上是 殉门 ««««*, 
s 不是 4» aa 叫声识扨 a 的费《。 
fi 不 itPogPoor 兵3? 


C:.f — ” 

体害户 * 來的印辑法 rt 。 f *. 
坻 ( j 紗现出系说的功糾. 
值用 碎说只 乂的" 


咱们让狗门总是自动关闭。 

因为 Gina 从未想让狗门没事就开着，狗 
门应该总是自动关闭，因此，我们把自 
动关闭狗门的程序代码移到 DogDoor 类 
中，于是.不论是什么东西打开狗门， 
狗门都会自动关闭， 
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需求变更 


E 新狗门 

让我们把关闭狗门的程序代码从 R « mot * * 中拿出来并放 
进 DogDoor 突中： 

public class DogDoor ( 
public void open() { 

System, out.print In (-"The dog door 
open = true; 


g 

DogDoor.java 


opens . w )； 




tTi ^> T . shio . 


timer, schedule (new TxmerTask() 
public void run() { 

close(); ♦ - 

timer, cancel (); 私 •， 

} 琛在狗 n 含 tisM 闭.印值戧 

), 5000); 们在加入打的新 设备. 

它 e *# 注 rt 。 大搏 5 ! 


的相阉的 《 序代辟— 


public void close() { 

System.out.println("The dog door closes. w ); 
open = false; 


简 化1 控器 

现在，你需要把这段相同的程序代码从 Remot * 取出，因 
为狗门会自己 关闭： 




最后的测试驱动 

自从他们打来电话后你已经为狗门做I •很多 改变. It 我 
fflSHW • F， ff H -切是 否 iK 常运作. <-i R»mot«.jav« 
及 D 0 gD 00 i:.j« V « 所做的改变能 U; 狗门自己 关闭， 再次编译你 
的*并 R 运行換 拟器： 



「潑- 

假如 Todd 和 Gina 决定要 ik 狗门开久_ •点.会发生什么？或者让它 
史快关闭呢？ 肴费你 是杏能想出办改变狗门，以便狗门自动关闭 
的时间能 It 客户自行设定. 





需求变更 


有时候， t 求的变真拈 
霹出兴子系练你所>庐 

实真是经第的， m 着侪 
每芬的实珙，系银总是 
m 泛改鲁 .， 

.^尖你的箝笔 

写下你自己的设计原则！ 

你已经在本拿使用了关于程序代码的重复以及狗门 自己关 闭的重 
要设计原则，试着为你已经学到的设计原_做个 总结： 


9 


㈣金<1本*我㈣个_普 
« 任稍后我们 金爲次® 1 ') 141 
尽《如 * t . 24尽力相 W ® 1 
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OOA&D 工具箱 




吏多 

工異箱里的工爯 


你已经在本章学到很多，现在足将所学到的添加到你 
的 OOA&D 工具箱中的时候了 • 在达一页做个复习，然 
后准& 把它们放进下一页的填字游戏中. 


f 求 


好的 t 求 磘保你 的系统如菩户辦 
拽期的蹕徉注 <1。 

磘认*求洛13系统的所有用例。 
注用用例找出審户忘5 者讷伪 的 

搴_ 

用 倒坍戏 *«何_7•宄 t. as 的 
電求.伢 g 杜 ■! 将它们加 ■•的 系 
统中。 

*求豸4«*«*)问汝变（及成 

长）。 


•口•珩 -个* 伢瓣 
f 求凍則. 

4供曾I 


00涿則 


将 ia 之物鉍装起來= 



鉍装 ㈣ 子制⑽》门料处扣 s 
的兵闭》4,,我们《狗0 的行的岛在角 
埤中的 ® 他伐存代铒分科。 




要点 

| 潘求总是随项 H 的进行而改 
变。 

| 当需求变更时，你的系统必 
须随之演进以处理新需求。 

| 当你的系统需要以新的或不 
同的方式运作时，就从更新 
你的用例开始。 

| 一个场 S 是通过用例的单一 
路径，从开始到结束. 

| 单一用例可以有多个场景， 
只要毎个场 R 都 fl 相同的客 
户 目标. 

1 神换路径可以是只发生在某 
些情况下的步骤，或者是提 
供完全不 M 路径通过用例的 
一部分的步骤。 

假如步骤在系统中的运作方 
式是选择性的，或者是提供 
替换路径通过系统，就使用 
子编号，如 3.1, 4.1 及 5.1, 
或者 2.1.1. 2.2.1 S 2.3.1. 

你应该总是试猗避免*复的 
程序代码。那是维护I作的 
恶梦.而且指向系统设计中 
的问埋。 
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需求变更 



OOA&P 垠字游戏 

字谜陆陆续续出埂.通过这个填字游戏，确认你已经理解本章的 
关钿概念。所有的答案部在本章中。 



横排提示 

2. We made this responsible for closing the 

4. This is what you follow in a use case most of 
the time. 

5. When your use case changes, these often 
change as well. 

6. Requirements always change over_. 

8. We had to odd this to our dog door to 
satisfy Todd and Gina. 

10- When your system changes, you should 
always update this before writing code. 

11. Use coses often have_ 

scenarios. 

12. Many real-world applications involve both 
software and 會 his. 

13. The one constant in software analysis and 


竖排提示 

L If a step is optional, use this in your ui 
2. Always avoid_code. 


7. Do this to things that vary. 

9. The main path is also called this. 

10. Every scenario in a use case shar 
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将你的软件 
带进真实世界 


是逐步发展成真实世界的应用程序的时候了。 你的应用 

程序可不能关起门来，只在自家的开发环境中运作、细致地调整 
以及完美地安装，而你的应用程序必须服务真实的人们。本章完 
全关系到确保你的软件能运作在真实世界的情境中 （context) 。 
你会学到文本分析 (textual analysis) 如何把你一直忙于的用 
例转换成客户所要的类与方法.当你完成时，你可以大 声说： 

“我做到 H 我的软件 Q 经准面对 典实的 世界了 | " 


这是个爱 ft 的世界 


一 R 狗，两 R 狗，三 R 狗，四 R 狗 …" 

Doug 的"超悴狗门"进行得很顺利。你刚才在第 3® 中开发的狗 N 版本疯 
狂大炎……然 Ifli 随符虹多的 狗门被安装，投诉已经出现： 
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分析 


你的轶仵有其情堍 

到 B 前为止.我 们一直 在与外界隔绝的情况 下编？ 3软件， 
还没冇想太多关于软件运行的真实悄堍 (context ). 换句 
话说.我们一 直像这 样思考我们的软件： 


在龙*的® 豕 
S ,人人使用 
我们 W ft 碑. 
就俅*们期望 
他们的邦 






然 i(ii. 我们的软件必须运作在真实的世界 41. 而不只&在 
完笑的世界中.这表示我们必须在不冏 W 境中考 ft 我们的 
软件： 





涿 i . 狗噼. *«. 
-gSf** 扣一桷 《 他麻烛 t» 
f * 鵝 tt 你的欽4。 


真实的世界 


系银迗作在 
其实赏界的 
憒埗里。 


确保 K 情正常运作以及典实世界不 会摧效 你的应用程 
序的关键垃 分析： 想出潜在的问越，然后解决那些 问題 
—在你将应用程序发布到真实世界之前， 
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识别问涯 


良好分析的第-步是想出潜在的 HM。 我们已经知进 
附近存在多只狗时垃冇 IW® 的： 


规划蘚决方案 



的 


尖你的铝 I 

^这个图解哪里不对劲？ 

想出要怎样修正狗门是你的任务.你可以增加，移除或 
改变步骤，由你决定。写下你认为需要的改变，接着在 
上图中标出你的改变. 









分析 


、鸾问％ 超 

% 


1®) : 我想致 不同的解法.那表示我的解法 
有误吗？ 


^ : 不是，只要你的解法让 Bruce 以外的 
狗都进不来就 T 以了 • 这就是让软件的讨论如 

令琪的方式缟®侪的伊 

此困堆的凍因：问題通常有一个以上的解法， 

le 总是没有'•唯一正确”的解法 • 

例。 

1®) : 在我的解法里，我把原用例的步嫌3 
换成两个步骤.而不只是取代现有的步驟。我 


错了吗？ 

^ : 你没错，只是因为问《通常有一个以 

户、经球和丼他扞英考 

上的解法，用 W 的編写也就不会是唯一的了， 

级如你用 T 一个以上的步 *. <S 确实处理了其 

展矛系银在其实世脣的 

他的叫的场景.那你使有 T ■一个有效的用例„ 

1®) : 那用例并非真的那么准确.是吗？ 

^ : 亨实上，用例是很准确的。 佤 如你的 

憒塊里扣何运作。 



用例本正磯讲述系恍应该做什么，你便会遗漏 
一痊* 求，最后使得客户不高兴， 

但是.用例不必非常 正式。 换言之，你的用例 
可能看起来不像我们的，我们的可能看起来不 
像其他人的。重点是，你的用例对你而言必須 
合 你範用 它来向同事.老板及客户做解 


除 r 第 iso m 所显示的之外，狗门系统还冇败耍的增柊要进 
行，是什么呢？ 
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持缕更新你的用例 


更新你的用例 


因 为我们 d 经改变 /* 狗门的1«解，所以必须回头符#狗门 
的用例，用我们已经想到的步骤史新它。 接荇， 在 f 面几 
K 里，我们会#理出程序代码所擗的改变。 


戧 C 0 移哚 7时鞾 4 i 人乌角的 
视从. ®^ C 4 个用例现 < S;t 合 
Oo«S WW 有睿户。 


终祖箱门， te 本 3.0 
构门要戗的事~~ 


主要路径 

人的狗在叫，吵著要出去。 
叫声识别器“咁见”叫声。 

3.假如是主人的构在叫.叫声识 
别篇送出谙求绐构门认打孖狗 
门。 

+狗门 打孖。 

5主人的构跎出去。 

6 . 主人的构办它的擧。 

6.1 狗门 I) 动兵闭。 

6.2 主人的狗在叫，吵著要进 
来。 

6•多 叫声轵别器“咁见”叫声 
(再一 次）。 

一 64 假如是主人的狗在叫，叫声 
识别器送出谛求给构门认打 
孖构门。 

6.5 枸门打孖（爯一 次）。 

Z 主人的构®来、进门。 

8.构 nt > 动打孖。 


2.1 主人細 M 的构在叫。 
J .1 主人按7通控器按钮。 


6.3.1 主人咁到 M 的狗在叫 
(爯一次）。 

6.4.1 主人按 T 遥控苕按钮。 



分析 



我们需要新的用例来存储主 
人的狗的叫声。 

我们的分析已经让我们意识到必须对用 
例做些改变，而那些改变意味着我们也 
要对系统做一些增修。 

假如我们要把叫声识別器的叫声与主人 
的狗的叫声作比较，那么我们真的需要 
在某处存储主人的狗的叫声，那表示我 
们需要另一个 用例。 




尖你的铝 f 

增加新的用例，存储狗的叫声 ； 


你需要增加用例来存储主人的狗的叫声，让我们把狗的叫声 
存储在狗门自身中 （Doug 的 Hi 件人员说他们的技术没有问 
題）。 运用下面的用例模板为此任务编写新的用例。 


这个用 

终极狗门， K 本 3.0 

® 巧迂*我们 的* 
二个用 anfn 

. 1. 

命名 

». <6.•: a <5« Cj 
闩¥滅路行* 
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你的铝 t 
解答 


增加新的用例，存储狗的叫声。 


你盅要增加用例来存储主人的抅的叫声， U; 我们把狗的叫声存储 ft 
狗门自身中 （Doug 的硬件人员说他们的技术没有问题）。运用下 
面的用例模版为此任务编写新的用例. 


我们不这*的 
鈿笮. 因的这4*4的 





终极狗门，胲本 3.0 
存储构 的叫声 

主人的桕“对基” 

箱门叫- _ 


2.检 TL 盔包+主.人 飴构_ 


% 


I ®): 你真的霈要全新的用例来 

存储主人的狗的叫声吗？ 

^: 是的。每一个用洌应该蛘 

述一个用户8标. **! 例的用户 B 标 
是为了 it 狗进出《门，則*在家里， 
而新用 W 的用户 B 标是为了存的 
叫声.因为这 内者的 b 标不 m , 所以 
你需要两个不 n 的用例. 


I ®): 这真的是良好分析的结 
果.还是只是我们在前两章早就该想 
到的结果？ 

: 也许有一点点以上皆是的 
* 觉 . 当然，我 *it 能 更早就 应该想 
到需要存 « 主人的狗的 叫声 . <e 那正 
是分析的内 a: 磯认你不会*掉任何 
可帮助 软忤在真实*界的情境里运作 
的亨情 . 


(®) : 我们怎样表示狗的叫声？ 

^: 好问题，也是接下来你必 

«w 答的 问题。 
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你知道你已经有一些类以及两个用例会吿诉你程序代码必须能做 
什么，现在，由你来想想程序代码该怎么 嫌改： 


任务： 

o 为狗门增加你认为可能需要的新对象。 

O 为 D °^> oor 类增加新方法来存储狗的叫声，以及另一个新方法来让其他 
类取得该叫声。 

® 假如 你需要 改变其他类或方法，在下面的类图里写下那些改变。 

O 为类图增加注释，用丁•提歯你任何奇怪 的属性 （attribute) 或操作 
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修理狗门 

两位程序员的故攀 

有许多方法可用来解决第 I55W 的设计拚图问埋。寧实上， Randy 和 
Sam. Doug 刚刚聘 i» 的开发者，他们两位都有一些很 W 的想法.但这 
里冇•件比程序设II •师的 紧的一 Doug 已经提供•台金光闪 
闪的全新 Apple Macbook Pro 绐提出®佳设 II* 方案的程序设 tl •师。 

Randy ： 简单儇是奚，对吒？ 

Randy 从不把时间浪费在不必要的程序代 码上。 他开始思 


舍* WW 的食新 Am>U 




en(): boolean 

llowedBark(String) 
llowed6ark(): Strinj 



分析 


Saw : 忠矣的对象爱好者 

Sam 可能 Randy 那么快，他深爱他的对象. 
W 此认为专职处理狗 叫声的 新类就蛙所黹 要的东 


Satntlb^ 


sound: String 


getSound(): String < - 

equals(Object bark): boolean 


SaHI 钊将夠 存 
•沒新 8 «* 中名巧 


.ig®B«fc 中 




^ . 叫 -lsO 方法让«他 

的象 etfe* 个 B * ,fc * 例 

尖你的铝笔 

根据类图写出程序代 码是一 件简单的事。 

你已经 肴到类 IS 给你的关 : !"-类的《性^；操作的 IT- 多信息，你的 
任务是根据 Sam 的 Bark ftR) 苟出程序代码. 我们 li 经勾了一 
点程序代码来帮你开个头。 

public class _ { 

private _; 



public 

this . 


Bark otherBark = 
if ( this ._ 


. equalsIgnoreCase (_ 
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4 尖你的铝 f 
解答 


public class 
訧 f 象 (Uiulii - 樽 . private 

S«m 值用 *&"* 

§<!** 择的狗 public 


根据类图写出程序代 码是一 件简单的事。 

你的任务是根据 Sam 的 Bark*R]i3 出程序代码， 这里是 
我们的答案 s 

Park 


S«m 的田。 



Sam ： 吏新 PogPoor 类 


因为 Sam 创建了新的 Bark 对象，所以在更新 DogDoor 类时 
他采取了稍稍不同于 Randy 的 途径： 


S«mft 本的 


(Sam 的) Dog Door 

疼嫌 Bwfcri 象 .® 

(Randy 的） DogDoor 

open: boolean 


open: boolean 

allowedBark: Bark 

c ~-^v 

allowed Bark: String 

open() 


open() 

closeQ 


close() 

isOpenf): boolean 


isOpen(): boolean 

getAllowedBarkO^arky；- 


getAllowedBark():(5tnnq7 
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分析 


fc 匕对叫声 

剩 K 的所有工作就足将叫押的比对加进 BarkRacogniMr 的 




// etc 


心 mS 经获珥 《#人5!的 
磋认.的现杏会 茇珥一 
个 8 响赛. *7.0.4^ 
^ Sni «f- « R „々_ 样。 


在 DojOooi 中的 Ba ， fc 的象 
让 If 比 》•) 的 i<V 他的 

cb?) HiH^' k 的象 


System.out.printlnf" BarkRecognizer :" 

"Heard a，" + bark.g«tSound(> + ''"•); 
if (door.getAllowedBark() .equals(bark)) { 
door.open(); 

)ela« ( 

Systam.out.println(''This dog is not allotrad."}; 


Sam ： 我将委托叫声比对的工作 

Sam 使用 Bark 对象，让它处理叫声比对的 工作： 
public class BarkRecognizer { 
public void recognize(Bark bark) 



// etc 
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类 》 at £ 

Saw 的狗门里的 委托： 

仔 细研究 

肴肴 Sam 怎么 做： 

O BarkRecognizer 取得要判断的 Bark 。 

Doug 的硬件听到狗叫，将狗的叫声封装在新的 Barit 对象 
中，然后传送此 Bark 实例给 recognize() 方法。 

[Bark 1 - >■ I recognize。■ 

/ BarkRecognizer 

狗的 _ 筹 《 f<(g 

«COJB;«()。 



e«k 时象 


O BarkRecognizer 从 DogDoor 取得主人的狗的叫声。 

rocognira 0 方法调用狗门的 g«t*llowodBarJc 0 ,取出表示主人的狗的叫声 
的 Bark 对象。 
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委托绕埵 


O BarkRecognizer 将叫声比对的工作委托给 Bark。 

r«cogni«.() 方法请求表示主人的狗的叫卢的 B*rk 对象，使用 Baric 
.■qu*l«» 苻它是否与 Doug 的《件所提供的 B«rk 实例相间， 


•* 麋得 (VW 知 0 * Pn ,«,» 
的 當该。 


喂， allowedBark. 你能看看我的这个 Bark 是否与你 
相符吗？我真得不太知进什么会让两个 Bark 相间，但 
我相信你一定知道。 



O Bark 判定自己是否与从 Doug 硬件所得到的叫声相同。 


表示主人的狗的叫卢的 Baric 对象判断它自己是否与从 Doug 个 

硬件所得到的 Bark 对象相同 …… 不管用什么方式比对 • F==. _0 在百¥存的 

你知道吗 ? 要知道另 - 个 Bar 咖方法就是接受它。 } 1 ㈣ 象 * 言 & '“ 

所以，看看我们是否真的相同吧。 






£»« 熳 

低耦含应用程序的威力 

在第|荦中，我们说 S 托有助干让应用程 序保持 
低綱合 (loosely coupled). 这表示你的对 ft 彼 
此独立.换宮之，对一个对象的改变不会引起一 
连申其他对象的改变. 

通过将叫声的比对委托给 Bw * 对象，我们把 
比对两个叫声的细节从 BarkRecognizer 类中 
抽取 (abstract) 出来，再次看看调用 Bark 的 
equals () 的程序代码： 


public void recognize(Bark bark)( 



"Heard a + bark.getSoundO + 

:- idoor.gatAllowadBaEkO .aqualsCbark)) 

door.openO; 


)else I • 

System.out.println(''This dog is not 


现在，假设我们汗始把狗的叫声以 WAV 文件的 
形式存储 ftBark 中。对干 WAV 文件，我们需要 
改变 Bark 类中的 equalso , 从而进行更高级的 
叫声比对。然而，由于 recognized 方法把叫声 
比对的工作委托出去，所以 ffiBarkRecognizer 
里没有程序代码需要改变。 

因此，有了委托与低網合的应用程序，你可以 
改变一个对象（像 Bark ) 的实现，而不必改变 
应用®序中的所有其他对象。你的对象得到保 
护，免 r - 受其他对象实现改变的 干扰。 





免矣敢件中 其他对焦 
宍珙欤实的午扰。 
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锣到 Sam 、 Randy 认及那场责赛 . 

有了 Randy 的快速解法以及 Sam 的更 |fii 向对象的解法，让我们石•■&他们的应 
用程序如何 运作： 

«Ci 









蓬门今始为君开 



Randy ： «是太可笑 r ! 我的解法运作正常，那台笔 

记本电 B 是我的，不是某个菜鸟实习生的！ 

Sam ： 拜托，老兄，我的解法也运作正常，而且我用了对 
象。你没有读过《深入浅出 Java 》 吗？面向对象的解法是 
必经之珞。笔记本电脑是我的！ 

Maria :嗯， 帅 Sf 们，我无意打扰，但我不确定你们俩的 
狗门真的有用。 


胞水不落外人 T ® ! 


出乎 Randy 及 Sam 的息 料， Doug 宜布 贏家垃 Maria. 
•位 菜电 级程 序设 计师，她来公5|暑期畚加实>|的， 
附带说明.地坫 Doug 的老婆的阿姨的女儿. 


利太敁 矽站.也 
锊.沩以在 4 * I 似时 * 玷 
傷—下•旮 MocBoofc P*。。 


Sam ： 什么意思？我们脷试过了 ， Bmce •叫•呜！ •门 
躭开了，而且对于别的狗的叫声，它也充耳不 W 。 我觉得 
没釘 N 理啊. 


Maria ： 但你们对你们的解法做过任何分析吗？你们的狗 
门真的能在真实世界的情境中运作吗？ 


Randy ： 小姐，你在讲什么火星语啊？你从火星来的吗？ 
Maria : 不，不，大哥别误会。我只是在想，万一 Bruce 
发出不同的声音呢？像“呜噜”或“噜噜 • ？ 


Sam ： 不同的声音？就像它肚子饿？ 

Randy ： 或者太高兴？ 

Maria ： 或者也许……它真的要出去上酮所。 
就是真实世界里事物的运作方式吗？ 

Randy 和 Sam : 我们真的没有想到这些. 
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那 Maria 做3什么不 一# 的擧？ 

Maria -幵始与 Sam 做的很像，她创垅广 Bark 对 ft 以表示狗 
的叫声. 


getSound(): String 
lequals(Bark):boolean . 


-站 J j g 
* 4 “iisO 方法进行凌托 .. 
抚偉 Sum 礙的_拜_ 


然而 Maria 想得 更远： 因为一只狗可能有不同的叫 
声，所以地决定 it 狗门存储多个 Bark 对象。那样的 
话，不管主人的狗怎么叫，它都能 出去： 



^方珀功 4 ii 殉 
0存样_个 w 上的 
B " kp ) i . 人的 



在5这 个 S 考 4 侑么金 


^ OUMU 大镜 




我们已经在类图中加了 -点新 东两： 


羼 《的多«作.说玥《« 
伐昶 保存多 少个* 鶉®*髻的 


allowedBarks: Bark [tl 

I 

attomfrfBflths 愚 ft 的逯 *4 / 此 f 彳代表 Mo„.dB»h s Uff-lUf, 
b«,i <。 84,4 的象的 




用例告诉你该做什么 





分析 


注 f 用例里的名询 

Maria 想到某件真的很重要 的事： 用例里的名词通常是你需要编写的类.而 
且是系统的焦点。 


尖你的箝 I 


你的任务是将下面的用例里的名词（人、地 ，物） m 出来，接着在页 
面底部的空格中列出所有你找到的名词（毎个写一次，勿重复）.翻 
到下一飪前请务必做完此习埋！ 



终祖狗门， | 

孖/兵狗门 | 

主集路技 

rx 人的构在叫，哕«8出*。 

铥 滅路径 

iTS 人咁到她的构在叫。 

2 •叫声 识扨8 “- fta " 叫声 • 

1.1 主人拽7逋 控器按 0。 

3.面如是主人 《< g > a 叫.叫声识别 


8送出惰求给 相门认 打孖鶉门。 

4. 鸚门打孖。 

5. i 人的构路出*。 

6. 主人的 典办它的搴。 


6.1 梅门 fc 动共 W 。 
6.2主人的》在叫.砂蘑*进采。 

6. J 叫声 ffi 別8 叫声 （* 

6.3.1 主人'的构在叫 
(*-^) . 

64® 如法主 人的构 在叫. 叫声 ® 

64.1 主人按 下遥控器垵钰 .》 

> 别器送出锖求给® n 认打孖》 


6.5 桕门打孖 （*- 次）。 

Z ± 人的»®*. 进门。 

1鶉 nt 动其闭。 



在这 婪空格 f g 
下达夺用例 l 1 ® 
i 的名 评。 
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名词分析 



构（主人的狗） 

叫声识别器 

构门 

主人 


榣控器 

按钮 

叫声 



a 辦有 w 用剜 r® 4的 

名薄 • 
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Maria ： 垃的，那就垃我发现盅要 Bart 类 的方式……它 
出现在步骤2和 6.3 中，因此我创达了 Bark 奘， 


Randy ： 那么，这就足我犯错的地方……假如我査肴过用 
例并圈出名词，我也会知道 要创达 Bark 类。 

Maria : 可能。有很多次，即使我认为我知道需要哪些类， 
我还是会利用用例里的名词再检査•次以确保我没有漏掉 
任何事。 

Sam ： 但对于有些名词你不需要类，像••主人”，“请 
求”。 


Maria ： 的确足。你还坫必须 A •叫*本常 W 件/•解你 iF . 


的系统。记住，只需要为你必須* 
承的系统部分准 ft 炎。我们 不黹要 用类表 
示“狗”. “济求 •■与“主人 - , 闪为我 
们的软件不必表 示这咚东西。 

Randy : 而且你不需赛用类表示■•按 
钮”，因为它是遥控 器的… 部分，而我们 
确实已经有类代表遥控器。 

Sam ： 是的，没错，但我-样也想到了 
Baric 类，我可不需要利用用例来找到它。 

Maria ： 是啊，但你终究没有想出-•个 S 
正可行的狗门，是吧？ 

Sam : 嗯，是没有……但那只是因为你 
在狗门里存储广-个以上的 Baric 对象， 
跟用例又有何干？ 


饲 （与动 f 目）％ 
鳌球出粦与方法 
的动作叫你关本 
欠祈 (textual 
analysis ) 。 
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全都乌用例有兵 

仔细看看用例里的步骤 3. 看看有哪些类真正被使用 


- i 人的狗" 4* 讲. <5我 
们不* •*>!) 它油备_个獒. 
因妗狗&夸耷老 (** w,) 
料 fl 存轚统外 ® 



/ 

多.假如是 主人的狗 在叫， 叫声 
识别器 送出@給 qjj 认打 

孖狗门。 a 个 fl»# (g-±^ 

—— ** $t. Li> Z 

㈣ 谈顯 0 i W „ 



isOpenf): boolean 
addAllowedBark(Bark) 
gelAllowedBarksQ: Bark [*] 


这里 M Park i f 

在步骤 3 这里使用的类是 BarkRecognizer 与 
Dog Door. 不是 Bark! 





分析 



吻含， 狗门 S 淡打开。 


s 的玥例的步廨 3 ■在这 

I. ~^P~ t£5- 
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这两个栋述碥实 布差别 …… 

厨起来 Randy 的步骤3真的有点不同干我们原有的步 W 3. 
里做错 T? 

3 - 1 

3. 假如是主人的狗在叫， 
叫声识别器送 
出清求给 狗门认 打孖 
狗门。 


那么 Randy 哪 

ii4 R«ni» 洚扣阄掏 n 斯 Q 
出 W 用例的读 * 3 

/ 

3 . 假如叫声识别 器所咁 
到的叫声岛主人的狗 
的叫声相吻含，狗门 
S 该打孖。 


M &： 主人的§_ 

原有的步骤3把焦点放在主人的狗上……不论狗 
的叫声听起来如何.因此，如果主人的狗某一天 
大声地叫“汪 • ，而另一天小声地叫“呜”，那 
么不管是哪一天，系统都会让狗 进来。 这是因为 
我们把焦点放在狗上，而不是在特定的叫声上， 



魚点：主人的狗的叫声 

Randy 的步骤3把焦点放在主人的狗的 
叫声上。但万一狗能发出超过一种的叫声 
呢？万一两只狗以极为相似的方式叫呢？ 
此步®看起来很像原有的步骤3,但实际 
上完全不一样！ 



开0, 
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I ®): 那你的意思 ft . 只*我写出 
用例.我的软件就会像它应该做的那 
样运作？ 

^ : ■*. 用 W 确实是通往编写 

伟大軟件的好起点.然而它的内 a 可 
不仅如此，记住.分析带你从用例里 
找出类。在下一幸.我们会花史多时 
间谈论在编写类中的良好设计原 
則。 

1®) : 我以前从未使用过用例.也 

没碰到什么问8。你真的认为我必须 
编写用例.才能 a 立好软件哄？ 

^ : 不.不是的.有许丨 禮长把 
工作做好的<1序设计押甚丑不懂用 w 
是什么.但是.《如想要你的软忤能 
* 让客户滿*.想要你的《序运作正 
确且不需要太多的*新修正.部么用 
W 真的能满足你的需*……特别是在 
你的老板或客户 * 前犯下令人埴尬的 
错误之前。 


1»): 名词与分析这一类材料似 

乎相当神奇.而我对英文文法宪全不 
熟.我该怎么做？ 

^: 你真的不需要太在意文法. 

只*以会活式的词谱写下你的用例 
(或任何你所说与写的语 言）， 然后 
整理出用《中的■•事 物" 是什么—— 
这些通常是名均.对于每个名词.想 
一想是否需要用类来表示它.这样. 
你便在系 蜣的真 实世界分析上有了好 
的开始. 


: 但万一我犯了像 Randy- 样 
的锚误.在用例里用了不该用的名词 
呢？ 

^ : Randy 的 M —在用例的 
步骤3中使用“叫声 • 作为名詞（与 
Randy 的文法无关，而是他没有&底想 
清楚他的用例以及他的系统如何运作 
在真实世界里。没把焦点放在让主人 
的狗出去，反而在担心莱一种特定的 
叫声。 他把重点异错 T. 

在编写用例时.你要反I读它.确认 
它对你而言真的合甚 i •你也可以 
让几个朋友或《事完整地读一读，确 
保它能运作在真实的*界里.而不只 
是在受控 M 的环境中. 


讀楚夂准确地斛释系银在侈什 

。 

有 : J ft 妗、奔轚的芹例， f % 一 
f 哿長整球出系银所霈 类的简 
单夂佚进的方 




分析的力量 



文本分析告诉你焦点在哪里， 
而不只是你该创建什么类。 


即使我们没有 Dog 类，文本分折也确实给我们 
关于系统真止:要做什么的重要 线索： 让主人的 
狗进出狗门，不管它怎么叫。换言之，我们的 
分析帮助我们了解焦点所在……不是特定的叫 
声. 


Maria 没有真正分析过用例，她是不会想到这- 


层的。 


人你的15笔为什么 Maria 不创建 Dog 类？ 

当你从用例挑出名 词村， 一个不断出现的名词是“主人的狗” •然 
而 Maria 决定不创建 Dog 对象，为什么？在下面写出三个你认为 Maria 不在系统 
里创 »Dog 类的理由。 





分析 


论住: 注意那些名询 f 

即使 ni 例 mi 的名词没有变成系统的*,但对于让系统如它应该做的那 
样运作来说，它们还是很* 要的。 


在用蜗！. _ i 人的柙 
4名说.(5典不 


不4杜争禕 r 


的^朗 SO bT 


3. 假如是主人的狗在叫，叫 
声识别器送出清求给狗门 
认打孖狗门。 


注意芹倒里的 

扪; r •是系痪里 
的炙。 


重点是^是你应该聚焦的地方。假如此步骤 
的焦点狗狗，你会想到你必须确保狗狗能 
进出狗门一不管它有一种叫声还是多种叫声。 


fefe 你确宍有 
的粪扣何夹持芹 



狗 . 这4用 

例1 -一_的 
w# 分 . 


DogDoor 


open: boolean 
allowedBarks: Bark [*] 

open() 

close。 

isOpen(): boolean 

aaaAiioweaoarK 

gelAllowedBarks 

BarkRecognizer 


door: DogDoor 


recognize(Bark) 


賴此方扣供隼-片齊它的 
0的2«找±4«—0角在叫 
达将 比时麹 Of 的鰣苟 O % 
看扑约声 «»* tl 主人的两， 


例所推迖的行 
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动词是操作 





分析 





程序代码磁铁解答 

多做.些文本分析的时间到了 • T 面是你一 K 在开发的狗门用例。在本豇底 
部的是 H 前我们系统 m 的大部分*与方法 • 你的任务是将类磁铁 y 用例里的 
名词相匹配，以及将方法磁 铁与用 例里的动词相匹配。 符肴那 些;/法与动词 
是多么--致。 


终祖狗 n , k 本 ？ .0 
^孖/关构门~~ 


蟹狳路径 





^ 狭.用例啄合 《f 

C44 •-个 《«兆， 因巧我 们的癡耷方法 
1砝(**它们在找鍁的*. 斯以 系统含 威功， 
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分析 


^[尖你的铝 f 
解答 


为什么 Maria 不创建 009 类_? 

，你从用例佻出名词时，•个+断出现的名词是“主人的狗"。然而 Maria 决定 
不创建 Dog 对象， 为什么？ V 面是我们认为 Maria 做 _fiR 确选择的个理由. 



1. 均在系统之外.你 a 常不 tai 在示系坑 


7 构不是软件对象（也不《是> ……你 a 常不会两类老示话的东8 
(living things ) ■ 賒昨系统将存铽兵子违粕的长期 信患。 


3. 即使你乇 Pog 类， 
S 的将狗“存砵” 


它也不会对系统的其余部分笮帮 助。 例如.饽不会 
在构 ni . 并不含 a - 


rr 工 rr 二二 

(一， W 


鸟 的类. 

免龟 (*■»<*) 臧存嫌 fg 
用十 -^ 
典不遠用子 iitf 


一 、奪问匈匈埋— 

I'?) : 所以用例里的名词转变成类.而动词转变成方 

法？ 

^ : 差不多。寧实上，那些名词是类的候选人.并 
不是每个名均郝是类。例如，“主人” 是用例 里的名 ifl 
(W 如步 *2.1 与3.1中> .te 你不需为该名祠准备一个类. 
因此，即使■•主 人- 是类的候选人，担它并本变成真实系 
仗 i 的类. 

以相 fl 的方式来看，动 ifl 是操作的候选人.例如，* 
然'•办它 的穿- 是 用例里 的一个幼词* 4 *, ft 我们不需 
要去写 p **() 与 poopO 方法。希望你认同我们的选择 .还 
有，文本分析螭实是*理出系坑所需类与方法的好开始. 


I®): 看来好像系统外的名词不会转变成类.那总是对 

的吗？ 

: 大部分时候是的，唯一的例外是你必須与系统外 
的某事交互操作 （inleracO 时——»系《•必 須重复 使用* 
种状态与行为时. 

例如，在« 门系统 里我们不需为■主 人” 准备_个类，因 
i^R«mot •类会注意到与主人有关的活劝.然而，如果我们 
要追«主人的状态，像主人是 《* •还是 《着，=1■能《•需要 
创建0»1>«1：类》 
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1^ 31 ^相-1 热衷于 UML 图……你能 ffl 解 地所完成的 •!： 刀吗？在下 面的类田甩， 
为所有她 LL 经增添的新寧物加 t. 注解， 试着想出这些线条、数字以及额外文 
t - 的惫 义 。我们已经写了一些 注解来 浓你起个头。 



Bark 


sound: String 
getSoundj): String 
equals(Bark): boolean 


■►芩索在* U 4 8。 
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关联与多重性 


类恝蘚析 

类图的内容可不只有方块与文字，来看看一些线 
条与箭头怎样为类图增添更多信息,， 

t 卜个"…个，^ 
^ IB ( assoei »«<®»). 它彖矛 1 
r - . . M 21 S\ 


•乘洚 R 

(soutc# class) s 枝 0 杉 
类 (l«S«J clttt) . 

7- demote (来涑类）有 
—个 DojOootS® (0 杉 
*) 的《作― 



不食 ft R 的 H 
«代表 w * 伐. 

Wf ® 


pressButton() 


flUow* 拍 a 如的爆1 . 


allowed Barks 


sound: String 

getSound(): String 
equals(Bark): boolean 






DogDoor 


open: boolean 


open() 

close() 

isOpen(): boolean 
add Allowed Bark(Bark) 
getAllowedBarks(): Bark [*] 









壤 UMUH 究解答 

Maria 相当热衷干 UML ffl ……孖 栺你是 S 能理解她所完成的 


这 tf 钱条 认内含 用 
(«<*«”《) WJtiittjt 



BMk 的象 ' 







& 尖你的铝 f 
^解答 


根据下面的炎 -ffl ,你能为 DogDoor 类里的 allowedBarks 属性使用什么类 >p!? 
在下面写下你的想法， 

Ust . Array . Vector 莘。 _ _ 


伐下 t 神多 的 1 ' 4 

何鼗 $ . 大都分的 

含 (CoUtelion) ft 背芍， 
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为何使用 类图' 


««««* 不礁定 
么**达《®…… 


Randy ： 我也 I 午错过了创让8«*龙.+过我的解法还算不 
赖.我可没冇浪费时间在那些矩 形与筋 央上， 

Maria ： 你没有听过••一阁胜千言”吗？ 一旦有了类图， 

我便对整个系统即将做什么有了很好的想法。 

Randy ： 见鬼 r , 谁听过啊？不过，我想我理解你的意思。 

但是我对系统要怎么工作也是有很好的想法的，它就在我 
的 B 子里。 

Sam ： Randy, 我想我开始改变我对这些 UML 相关亊项的 
立场了.我是指，■•旦有了用例，你很自然就会去做一些 
分析，将名词转变成类，好像就不必花那么多时间担心什 
么应该是类，什么不应该 是了， 

Maria ： iK 确！我讨厌 W •堆类，然后发现我做铕了某件亊。有了用例和* ffl , 假 
如犯了某种错俣，我只轚擦掉它; * 新绘 It ) 即可. 

Randy : 嗯，我想没错.重新编 y 程序代码比重绘类 ISE 花时间。 

Maria ： 是啊，假如你必须与其他人共同合作，你会向他们解释你瞄子里的系统， 
对吧？ 

Sam ： Randy, 我想她是对的。我已经领教过你在解释系统时所両的白板……真是 
够了！ 


Randy: 好，好，我承认。不过我还是认为类图并没有把整个故亊讲淸楚。如程序 
代码实际上是如何比对叫声并决定是否应该开门等？ 



00A&04 s 4 *. 
你出(辠 

4 00A&0 枝** 
饬存代 
场 中犯搏的一种 





分析 


类樹不是一切 

类图是取得系统概况的好方法，可以向同亊和 其他程 / T •设计师展示 
系统的各个 郎分， 然而，还有很多亊是它们没有显示 出的， 

类图提供的类型信息有限 


Bark 


DogDoor 

* allowed Barks 

f 

sound: String 

open: boolean 

getSound(): String 
equals(Bark): boolean 

J 

open() 

dose() 

isOpen(): boolean 
addAllowedBark(Bark ) 女 
getAI lowed Barks(): Bark [*] 





类图没告诉你如何为方法编码 


LJ 


_ - —v//_uns 


| _子这® 中 

fetAllomeJBatksOa © 
ft « * * .• 


类图只给你很粗略的系统概述 


Remote 

door: Dog Door 
pressBultonQ 



4 ® 州不 

•用髴求+ 5 衫 
t*)0« 
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类阁有助 F 为你潘要创逑的类进行达模 (modeling). 但它们并没存提供为系统编程所需 
的一切答案 • 你已经看到狗门类图并未告诉我们关于返回类型的信息，还有其他什么亊是 
你认为是为狗门编程所需要知道佴在类图里并不清楚的？ 

为下图加上注解，说明为狗门编程所需要知道的事。我们已经加上关于叫声比对的注解来 
帮你起个头。 





那么现在 recogwizeO 如何运作？ 

Maria 已经想到地的 B . rkR . cogniz . r * 应该能把它接收到的叫声与多个 
允许的叫声进行比对，俱她的类图并未告诉我们多少关于如何实 R 编写 
racogniz «() 方法的倌惠< 

实除上，我们必须看# Maria 的程； T •代码，这电垃地的 B *«: kR « CO g n ii « r !)| 
的 r « C ogni *«0 方法，以及地如何解决这个关于叫声的问题： 


public void recognize (Bark bark) { 

System.out.printlnt" BarkRecognizer: Heard a '〃 + 

象 . i £ 莪们 g 途 bark.getSoundO + 

W ( 这代）列表中 List allowedBarks = door.getAllowedBarks(); < —一 
的 * — 个场 0: ' for 'Iterator i = allowedBarks.iterator (); i.hasNext();) 


鲁个 《 表。 


比的 Wirti 托 
铪 e«ib 的象 



Bark allowedBark = (Bark)i.next(); - __ 

if (allowedBark.equals(bark)) { 我们抵认 1 «***° , 济射的 

door.opan(); S 个 》 5D 鸫窄 （ c«t) J6 

return; * - 象： 

1 0 -軚婷士蛘》的3代。 


System.out.println(''This dog is not allowed."); 


托： 

i 的(声. 


Maria 的文本分析帮她想出 BarkRecognizer 必须 
把焦点放在所涉及的$上，而不是那只狗的叫声 


•此方沾把«魚故4 # - 的 U 

£…… fester 

神 声眘. * 不 4« li . 0 •物 本卑. 




谜题解答 


4落的一禳 

为下图加上注解，说明为狗门编程所需要知进的亊。 


习超 

裤答 



♦ 这. 0 .*_螫戧们 S 到的搴.伢的爷案可抽 龙全不 
同。似如你 S « 类®沒有4正8 芳的典 他辜.尽 IS 
° e . 找«仿•坪夹 落的一 免。 
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设计拼图 


珙计拼窗 



除了显示在下一贸的 DogDoorSinmlator 以外， Maria 的旧电脑弄坏 
了她为狗门编写的所有程序代码。你必须根据本章中地的解法的程序 
代码片段.类图以及你所学到的关干良好分析、需求与 OO 编程的一 
切继续进行下去。这一次轮到你成为英雄了…… 

问题： 

你必须为狗门应用程序编码， ih 它满足 Doug 的所釭新客户， 

特別邻近有多只狗的那些人的锯求.该狗门应该运作得 
躭*本铁用例所描述的系统那样。 


任务： 

O 从重途第3章所描述的狗门应用程序开始。假如你想要跳过这个步骤，可以从 
Head First Labs M 站直接下载这里的程序代码。 



Q g 制或下裁显示在下一页的 DogDoorSimulator.java^ 这是 Maria 的旧电脑 
坏后唯一幸存的文件。 

O 确认你的程序代码符合第180页所示的 Maria 的类图， 

O 开始写程序！先把注意力放在让所有类都能编译 t , 因而能够开始进行测试。 
0使用 DogOoorSimulator 炎，看看事 情是否 按部就班地进行。 
o 持续分析与编码，直到测试类的输出与下一贝所示的输出相符。坚持下去， 
不要放宑！ 

O 一 i 你认为有了运作正常的狗门，躭检査你的程序代码并与我们在 Head First 
Labs 网站上的相比较。 
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连♦连 着 我是谁？ 

UML 与用例有许多术语，类似但并非完全相冏干你所熟知的编程术语。下面 
是一些与 OOA&D 相关的术语以及它们的定义，但毎一项都弄混了。将各项与 
定义连接起来，把混乱澄清。 


樣作。 



达是 UML 的术语.通常代表类中的方 
法。 


帮你螫 *1 出系统中对象上的 方法傾 迭者。 


在视®上五示一个类乌另一令类布兵系. 

常常通过厲性实现。 


等商子类中的成员变量。 


描述布多少个特定类型的对象能#锌在 

类的展性里。 


你对用例戗这项工作.技出系统所*要 

的类。 




横排提示 

1. Use cases should use this kind of language. 

5. Every class diagram has one of these for 
each member variable. 

10. This focuses on putting your application 
into the correct context. 

12. Software always works better in the 
testing lab than here. 

13. Maria won the laptop because she paid 
attention to the 

14. This relates one class to another 

16. You write your use cose so you can 
_your customers 

17. Use cases should be_as well as easily 

understood. 

18. UML is this type of modeling language. 


竖排提示 

2. Analysis mokes sure your application works 
in this place. 

3. An operation is UMt-ese for this. 

4. You do this to your use cases to figure out 
the classes and operations in your system. 

6. He replaced Fido as this chapter's star. 

7. Class diagrams are a great way to get this of 
your system. 

8. How many of a type an attribute can hold is 

its _ 

9. These types of diagrams are worth a 
thousand words to a programmer. 

11. Use cases aren't formal, but they are 

15. Verb is to operation as this is to attribute. 




习涯 

薄答 



线 4 着 a 是推？ 

uml 典似 m 件阳完 fttwioir 你所的编 

« ^ViooAaDWK 的术 i«u 及它们的 定义 . m»» -flmt/fKr. «* 項 
定义 (eaestisin. 
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5( 第一部） 良 好的设计= 灵活 的轶件 


诸行无常 



改变不可避免。 无论你现在有多喜爱你的软件，它很可能 
明天即将改变。你的软件越难改变，就越难响; •:/: 客户需求的变 
更。 在本荦，我们将质新拜访一位老朋友，试着改善他现有的 
软件项目并且看#小变更如何变成大 问賊。 亊实上，我们将发 
现问题的确很大，以至于我们必须采取两部分的章节来解决。 


进入新章节 197 


超越吉他 茲乐器 

Rick 的舍 A 让 


0 上 


Rick 的新系统初 W 啼成功将3把吉他矣给摇浓闭体 Auguswna. 他 
的吉他亊业电胜以往，蒸蒸日上一你在第1茕侬 Rick 构让的搜尜工具 
正是他的來收的*石， 



点* 我们想想 _R 新构造他的;.V:用程序以 i •持丑陀钵会冇多容沾。 


198 V 


►译注 I: Nashville. 位于田纳西州的 Nashville M. 是 *B 乡村音 
乐的 i 城.洗什音乐的犮源地，曼陀林 . 一种拨 《乐 s. 
是美国乡村音乐中最具特色的佯奏乐8之一， 




良好的设计 = 灵活的软件 


4尖你的铝 f 


为 Rick 的捜索工具增加对曼陀林的支持 


1、•面垃 Rick 的吉他搜索应用程序的完整炎 ra, 躭和我们在第 1® 完成时.样.山 
你来增修此图，以便 Rick 可以开始销饵®陀怵，而且你的拽索工 u_ 能 m 他找到 
符合客户喜好的曼陀林，就《为 ,■*/ 他做的一样。 






















注意到紬象基 类：？ 码？ 


良好的设计=灵活的软件 


仔细 fl'fi •我 ff I 新 it 的 Instrument f ： : 


getSerlalNumberO ： String 
| getPrice (): double 
ice ( float ) 

iec (): InstrumentSpec 


Afnnd < s« iu, * 

MandoUn 共用的 ® 

性 (attutute) 作 
( oftiation ). 坍它们故 

进 JnsH«>"«* ! = 


柚象类是宍标的 
宍珙夷的 占位符 
(placeholder) „ 


Instrument 是抽象类，这表示你不能创建 
Instrument 的实例 （ instance ) 。你必須定义 
Inatrunent 的子类 ( subclass ) ,像我 fN 逮 i 

的 Guitar ^ Mandolin ： 




Instrument 


serialNumber : String 
price : double 


getSerialNumber (): String 
getPrice (): double 
setPrice ( float ) 
getSpec (): InstrumentSpec 

^ 〆 一一 



的募 *. 会 

们值真行巧* ¥子赛类 


Guitar 

Mandolin , 

gelSpec (): GuitarSpec | 

getSpecO : MandolinSpec 1 


1。 


4 子 t 3的方式贫现 4 义 
«中的《(1。 


•在 


我们 it Instrument 抽象化是因为 I 


是实际乐器 （像 Guitar ^ Mandolin ) 的占位符 
( placeholder ) 。抽 ft 类定义一些*本行为.但这 
些行为的实现垃由该抽象类的子类负撖增加的. 


Instrument 只是为实阮的实现类预先占好位 S 的通 
用类. 





新增 MandoiinSpec 


我们也会 f 要 MandoiinSpec 类 

Mandolin 与 Guilar 相似,但有几件事与 Guitar 不同……我们能 
WM*ndolinSp«c 龙捕 促这呰茇异： 



202 i 
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V 问 贫匈堪 

% 


1^) : 我们把 Instrument 抽象化是因为我们 

把 Guitar 与 Mandolin 的共同特性抽取到它里面，对吗？ 

^ : 不.我们把 Instrument 抽象化是因为 B*T 在 
Rick 的系统里并没有实际的“乐器” (ins(rumenl) 这种 
东西。它所做的一切是提供一个共同的地方存 《P1 时存在 


:我们不能对 GuitarSpec 与 MandolinSpec 做 
一 样的处理吗？它们好像有很多共同的厲性与操作.就 
像 Guitar 与 Mandolin。 


^ : 好主意！我们可以刻建另一 个扯象 的基类，叫 



于 Guitar 与 Mandolin 类里的特性，忸因为乐》 0 析没 
有其子美以外的什泠.所以它真的只是在定义所有乐 S 要 
实现的共《羼性与特 

因此.即使我们将两种 乐器矣 型的共同特性 •!* 取出来.也 
不必然表示 Instrument 必坝是抽象的。事实上.我们 
可能在以后 it Instrument 变成一个实体的 <concrelc> 
类.假如坏对我《的设计是合理的。 



让我们拕毎件事组含起采叱 r 




抽取共同行为 


醮： Rick 的新应用程序 

看来第I章所有的设计工作都有了回报,为 Rick 的授索 lift 增加 
® 陀林的4：持庀 r 我们小•超过10豇的苡幅《这甩垃完成; n •的* 

w ： 
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良好的设计 = 灵活的软件 


每当你 在 两个或两个多 上的勉 方找 
到矜伺行为时，止心姑将该行为柚 
聆 到-个 炱里，然厉％牝艿 i © 粦重 


芹诿項行为 






再 多一点 UML 


类穆解析 (再一次) 

既然你已经增加 r 柚象类.子类以及新类型的关联.现在是为你 
的 UML 与类 rt) 技巧升级的时候了。 


名 li/ •斜 体表矛 的， iS ft 4 j*£_ 

的 fliif . #H 们不乂 "¥it 
7T s «“m«t 的 * W . 它只 4 破用來 
S 的泳葚爱（薄 •& Maniolin) H. 


这条 it •布蓋杉的*钱表杀 搴會 
K 合 i * 表-子一4攀#>4 

由系 一4 事浼（舴分蟪） 述钱 （ * ii2) , ©此. 
J n «tiw«xt 的 -Sf 分4由 Jnsli«me«tSpec ffl 4. 




译注2: f 实上. 在 IIML 里.对此更严 ijt 地 E 分为聚合 （aggregation) 与合成 （composition). 聚合以空心 t 形实残表 
示，表明一个类实际上拥有 te®T 能共有 （own bul may share) 另一个奚的对表， W 如作者 owns 论文（而能 
只是共同作者> • 而合成是比 K 合还*强的 关系.以实心 * 形实线表示，表明另一个类的对象实际上是此类本 
身的一部分 (a pari of). 并 Aii 常不与 系仗其 他_分共有，例如摘要与正丈 arepartsof 论丈 （论文是不会与别 
的论文共) fl 正文或摘要的，如果论文被 刪除. « ♦与正 文也会被删除> • &无论是 R 合还是 合成， 对化仰的《 
序代磷实现都一样会导致属 性的？ I入. 


►鋒注3: 


也称"一般化" • 
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良好的进计 = 灵活的软件 
«本5物*. 、 

麵 ® 來看赛 。 、 




在 Java 里的 

在 UMI •里的 

在 UMI •里的 

表示 

抽象类 

(abstract class) 

抽象类 

(abstract class) 

斜体表示的类名 

关系 

(relationship) 

关联 

(association) 


继承 

(inheritance) 

泛化 

(generalization) 

- > 

聚合 

(aggregation) 

聚合 

(aggregation) 

- O 


>常问句 肉超 

% 

:还有更多的符号与表示法是在使用 
UML 时*牢记在心的吗？ 


^ : 是的.有*多的符号与表示法在 UML 里， 
钽这要看你使用11\«_的《度.很多人只用你己经学到 
的#*基础的.也用得钿当燴快 （他 们的客户和经 a 
也 是）.仨有* 人則4■欢深入 UML , 使用 UML 工具 
»皇的♦一种技巧。这真的是*看你6己，只要你能 
泠达你的设计.与人进行沟適.便已《达成 UML 的意 





b Rick 的斩搜 fl 贝编码 



接下来，我们■要承做 Guitar.j*va 并为曼陀林创达- - 个* • 这两者都坫 
继承 instrument 以取得共同的乐器特性，接着以正确的规格类型定义它 
们自己的构造 函数： 






良好的设计 = 灵活的软件 


为乐器规梏创建一个紬象类 

处理好乐器之后，我们可以开始进行规格类的工作。我们黹要创 
逑另一个抽象类 In.tru«.ntSp«c, 因为许多乐器邯有共 N 规格 
的 部分： 



public boolean matches(InstrumentSpec otherSpec)( 
if (builder != otherSpec.builder) 
return false; 

if ((model != null) && (imodel.equals(""X && 

(imodel .equals (otherSpec .model))) 


return false; 

if (type != otherSpec.type) 
return false; 

if (backNood != otherSpec.backWood) 
return false; 

if (topNood != otherSpec.topWood) £ 
return false; 

return true; 


_ 个: ^ 

.... 


5 子类中 
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GuitarSpec.java 





•还有 MawdoliwSpec 


处理完 GuitarSpec 之后， MandolinSpac 也相当简单， 

它非常*似.只蛙多了 •个成 员变* 引用 曼陀钵 的样式 
(像 “ A - 型或 “ F ” 型）， «« tch .»() 方法也稍有 不间： 

public class MandolinSpec extends InstrumentSpec { 

__ _ o 44,« Style. 因此这不金破长)土拍 

private Style style ; •'^ 1 ^ . 

(g !•) Jnsttam««tSp*c SET.., 

public MandolinSpec(Builder builder. String model. Type type. 

Style style. Hood backHood, Wood topWood)( 
super(builder, model, type, backHood, topWood); 
this.style = style; 


// Override the superclass matches" 
public boolean matches(InstrumentSpec otherSpec) 
if (isuper.matches (otherSpec)) 






完成 Rick 的搜索工異 

所 fi 剩下的工作是 4£ 新 Inventory *, 以使用多种 
乐器类型 . 而不只 SGuit«i:*: 


inventory: Instrument [*] 


public class Inventory I 
private List inventori 
public InventoryO 


invcnlotji 表现 <5 存 ft 3 

多神玲 » 不 4只 
有*坫。 


I LinkedListO; 


= 〒值用 * }n s „u mentSptc 


public void addInstrument(String serialNumber, double price, 

Tnai-r-HiiientSpec spec)«1 - 

Instrument instrument = null; _ ___ 

if (spec instanceof GuitacSpec) ( 

instrument = new Guitar (serialNumber, price, (GuitarSpec 
)else if (spec instanceof MandolinSpec)( 

instrument = new Mandolin(serialNumber, price, (Mandolir 


inventor y.add (instrument); 


! serialNumber) { 

=inventory, iterator(); i.hasNextO; ) { 
i.nextO; 

i£ (instrument.getSerialNumberl).equals (serialNumber)) 
return instrument; < — 



•• 这不 * « 好. ® 碎 
硃 84 处 * 的 . 井 fj 不 ft 

的 1<1。 


' 系 _ 个(史用抽 象蓼类 

让我们 的设 刊蛟 * £ 法《的重 


// search (GuitarSpec) woi 




s before 


public List search (MandolinSpec searchSpec) { - 

List matchingMandolins = new LinkedList (); 
for (Iterator i = inventory.iterator(); i.hasNextO; 
Mandolin mandolin = (Mandolin) i. next (); 
if (mandolin. getSpec (). matches (searchSpec)) 
matchingMandolins. add (mandolin) 


我 (H 倉鬌另 _ 个 sttiehO is 

甩林。 


return matchingMandolins; 


fO ib . 伢 3 经备好 •: W 试 Ricfc 的 86 农后的左 
用《瘩。 伢 * 5 •拥 t S * 扣 Find<iuiUtT, t ut4 
罨看 S 么 Ldtisit? 
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v % 

Guitar 与 Mandolin 的内容 i ®) : 但是.由于把 

那似乎有点笨。我们 Instrument 作为抽象类. Inventory. 
躭霈要为毎一种乐器 java 里的 addlnstrumentO 方法变成了 
? 我们的痛处！ 


I ®): 没有什么中间地带的妥协 

方案吗？我 ft 说即使没有像"乐器- 
〈不是 吉他. 曼 陀林或 其他） 那样的 
抽象玩意儿.我们好像还*会有某种 


我们需要，至少就 
你如何分辨曼陀林 


那些子类让我们在构造函 


你无法创建一个 Guitar 并 


^ : 你是说第 212 R 的 

addlnstrumentO 吗？是的，由 
于 Ins tr ument 是抽象类，你确 
实多了一些额外的程序代码*处 
理，但是，为了螭保你不会创建 
一个没有真正存在于真实世界里 
的 Instrument , 这样的代价并不算 


ec 到 Guitar 的大， 



料 t 辜邮姆 用⑽中”不 。 
糾，你 抑- T . 
们卯埒*鈹的 —- 



设计问题.对吗？ 

^: «,你可範已经掌搓了某些 

要点，某部分《序代碼好像会受益于 
实体的 Instrument 类，而其他部分 

則 不会. 


有时这表示你必*以某种方式作决策并 
且得接受妥协方案. < B 是，这里或许还 
有更多事情我们没有考虑到…… 


I ®): 为什么我们有两个不同版本 
的 searchO? 不能将它们结合为接受 
InstrumentSpec 的 单一方 法吗？ 




因为 InstrumentSpec 是 


抽象类，就像 Instrument ， 所以 


Rick 的客户必须传送 GuitarSpec A 
MandolinSpec 给 Inventory 中的 





主要的改薷 


/ 达 A 的孖治«起采 好丨 ttffi 

达《»*#玎认«*们《免任何重氯的《序代 
*8. *fi 我们 也讲承 8 特 《封*«*格«中。 




你已经对 Rick 的应用程序做了 
—些 主要的改善。 

你所做的一切远超过只是为 Rick 的应用程序增 
加对曼陀钵的支持。通过把共冏特性与行为抽 

取到 Instrument 与 ZnstcumentSpec 类中，你 


已经让 Rick 的应用程序中的类更独*。那是设计 


上的重大改笛。 





強往佯大软忤的三步骑(重坊） 


良好的设计=灵活的软件 


Rick 的搜索工具是伟大的软件吗？ 

还 U： 得我们之前谈到的编巧伟大软件的： : ik 我们来 HWi 
下.#看我们在最后版本的 Rick 的拽索工具上落实得如何。 

1 . 新搜索工具做它该做的事了吗？ 


2.你己经运用了坚实的00原则（像 封装） 来避免重复的程序代码 
并且让你的软件容易扩展吗？ 


3.重用 Rick 的应用程序有多容易？对应用程序某部分所做的改变 
会迫使你在应用程序的其他部分做许多改变吗？他的软件低網合 
(looselycoupled) 吗？ 
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这是伟大软件吗 '? 


辟荅 


Rick 的搜索工具是伟大的软件吗？ 

还记得我们之前谈到的编 y 伟大软件的•:步骤吗？让我们来回顾 
下，看看我们在最后版本的 Rick 的搜索工具上落实得如何 • 

1. 新捜索工具做它该做的事了吗？ 

8»。 e«Wf 供 A1K#, 霣»不是》 对。 达驊 的坩. _ 

gtfSJI 做3大»分它曲该供的攀。 *» WWRI « k . 碥认 _ 

-T. _ 

2. 你已经运用了坚实的00原则（像封装）来避免重复的程序代码 
并且让你的软件容易扩展吗？ 


« 们值用？封浆 ■ g 我们孖 

■jg Instrument a iHStramewtSpee 我们值用 3 鷂承 . 

<sa 我们芘 3 很多 工夫.才完成新乐 8 类型的坩加 …… _ 


3.重用 Rick 的应用程序有多容易？对应用程序某部分所做的改变 
会迫使你在应用程序的其他部分做许多改变吗？他的软件低《合 
(looselycoupled) 吗？ 





a a 在 -te. SlmfruweirfSpec 拳实上是 Instrument W- 朗分 （g 


你 <;一螯* 我们不 _ 
样的爸 ffeS •:在.押 
也 P . 麓 * i « 你 

兵我们的爸* 

««■? 
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良好的设计 = 灵活的软件 



要看看软件是否设计良好的最佳方式之 
一是试着改变它。 

假如你的软件不易改变，可能就有一些设计上 
的问题可加以 改善。 让我们看看增加几种新 
乐器到 Rick 的应用程序中有 多难： 


一种个史 


法的級嫌 …… 








墦墦……增加新乐器稃不容易 

假如变更的容 S 性是我们决定软件是否设计良好的方式，那 
么我们在此便有一些议理。毎次我们要增加…种新乐器.就 
必须增加另’-个 Instrument 的 _f •类： 


Instrument 

a — 

serialNumber String 
price: double 
spec: InstrumentSpec 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
qetSpecO： InstrumentSpec 


然后，我们也需要一个新的 In 
类： 

InstrumentSpec | 

model: Siring t 


\ 

* S f*) Ri £fe 矗后不從携 s 
卖多 少种 承* 的.-个乐 8 
S* 贪 <5 ■-个类的搴实含任 
你決 A& 电! 


getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
malches(lnstnjmentSpec): boolean 


BanjoSpec 


getNumStrings(): int ^ - 

matches) BanjoSpec): boolean 


_ 奋这 丨.我 (Off 祐有 5_电 
， * 1吸终 代坏 ••••_• a 挛 

乜.《*迖个»«不*3用. 
不足 W 移 « 类 ！•. 


接着，当你必须更新 inventory 类的方法以支持 
新的乐器类型时，事情开始变得 棘手： 


- -荚子 。“， nstiume 

'iSs>Mzi2 ^ 

S 的 

邦發 inst4 » c«ot k *</ e * s * 

喝， t 辞的 sj .8 史* « 多. 

鑪不芍 枝耠。 

WAoee «. xi 8« 

a ** 的坩加 荖定珥霞颅人 
现乜. 我们 t « 新鈑本的 
S ««*0 is <4 iffa # * 


Inventory 


inventory. Instrument [*] 


addlnstrument(Slring, double, InstrumentSpec) 


get(Slring): Instrument 


search(GuitarSpec): Guitar [•] 


search(MandolinSpec): Mandolin [*] 


search(BanjoSpec): Banjo [*1 < -- 



的闲鼉， 






良好的设计 = 灵活的软件 


那么，我们现在应该傲什么？ 



看来我们确实还有一些工作要做，好将 Rick 的应用程序转 
变成真正容易改变和扩展的伟大软件。但这不表示你已经 
完成的工作不重要。很多时候，你必须改善你的设计，找 
出一些早先并不明显的问题。既然我们已经运用广-- 
些00原則到 Rick 的搜索I具中，就应 
该能够找到一些必须解决的问题，假如 
我们不想花接下来的几年时间去编写新 
Fiddl •龙的话（有谁会真的想要这么 

然而， 芘你准务 WMiK 处理 Rick 的应用程序下个阶段 
的 M 埋之前，这些事是你必须了 解的。 if 吧，如*没 
有进-步的问 H , 休息片刻.收看一下…… 


穴灾游! 


对象村最受欢迎的机智问答秀 





00 穴灾姐! 

对象村最受欢迎的机智问答秀 


「著名 1 

「程序 1 

「 

维护与^ 

( 软件神经 

[设计者 


L 

重^ i 

卜能症 j 












: 或许看起来不大像，但我们确实正在以■•说 ■•的 
方式改进 Rick 的搜索工具.我们需要一些相3高《 
的00技术让应用《序史足活且可 玄用， 我们想要在你开 
始把这*技术 &用到 1杂的问《之前让你先尝尝这*原 

1®1 : 我们为什么在这里玩游戏？不是*脩正 Rick 的 
搜索工具吗？ 


^: 从本幸找出符合答案的问题并不 te 你应该 
能够把它们全都推理出来. 馒 慢来，重点是尽 Tft 自己想 
出这* 问接着才能 to 到下一 R , 以取得问*的 更多信 
息与所涉及的 oo * 則.此外，我们认为你正在* t 变成很 
蝽的开发者.我们对你有信心. 

I®) : 假如这些 ft 新的00原则.我该怎么想出问《是 

什么？ 





在编写与这些类交互的程序代码时你有两种 选择： 你 - f 以编码 ft 
接与+炎 ((ft Footb « llPl « y . r ) 交互，或者你 SJ 以编时 1 j 接 |1 
(即力 Athl « t «) 交互。面临这样的选择时，你佐该总足偏爱对接 



ma 对孥 p 编碚, 
你的栈序代啐将 
值用 m 孥 p 的浙 
有孑类，甚至是 
铱 浼铱创建 的 
抑些 。 


为什么这是很重要的？因为它为你的应用程序增添灵活性。取 
代让你的程序代码只能使用特定子类 （ fifeB ««. b « llPl « y « r > , 
你可以使用£通用的 Athl _ t «。 这表示你的程序代 丹将使 
用 Athlet * 的任何子类（像 HockeyPlayer sfi TannisPlayar ) , 
甚至是还没被设计出来的子类。 
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“f 十么是红莖 (ENCAPSULATION) ? 

/K 避免程序代码8紅方面我们已经谈了好一咋封装了.但 是封装 
除 f 避免程序代码 ® 复之外还有I午多内涵， 它也浓 助你保护类免 

于不必要的改变。 


任何时候3你认为应用程序中有某种行为很可能改变时.你经常 
会想要把它从应用程序里不改变的部分移开。换言之，你应该总 

是将变化之物封装起来。 


这4激三件攀的 
葡辈炎： _ 
(« s * l ) • ( fJS ® 

% ( ilKSh ) blfi * 
( paint ) ffi o 



淖备本亲鸟: .fjf 圣笔 
,3*7 会変劫。 


« JF ® ® * ： *»的衫式含4功：笔 
鉍的 illf 食 4 处. SS 1«® 的潼度 
也古 ti # © rtiil 4 所有芍拥盔法 


p a i n t«fi* 有两个相当稳定的方法，但辦^以》方法在实现 t 
則有相当大的变化。因此我们将变化之物封装起来， 将闰家 _图 
的实现方式移出 Painter*。 


P«'«Sort •代 表各辞 
不用的®®行; 
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每个类都应该试图确保这件 


事的发生只有 


个理由 


件事代表许多设计不良的软 


件片段之死, 


f 十么是 


问題与答案 ► 








“ 仔么是 ^ (CHANGE) ? - 

你已经知进软件的不变真押.就垃“变”。设 I 十不良的软件 
在变赵屮失败.而伟大软件能 轻姑地 应付变史。 
it 你的软件对变®具有灵活性与 S £ 原力的最简申.的方法， 
躭是 确保每个类只有一个改变的理由。 换宫之，通过 
W 少引起该类的变动因索,就可以让此类发生变动的机会 
最小 fir 


♦罨 此免中的方•:在。_ 

它们 4i *1 * y Automobile 

i. 病轮跆 . — - 

认…料 - 3! 

耷減机文•、 * changeTires(Tire [*]) 
drive() 

| V wash() 

^ ， checkOil() 

、 - - getOil(): int 


、 ■箏 ㈣ 鉍电4.私 

HlfS 


当你看到类有一个以上的理由要发生改变时，它很可能 
正试图做很多事，看看是否可以将其功能分解成多个类， 
每一个类分别只做一件事——因而只有一个改变的 P 




问题与答案 ► 





















«« 穴灾沮！ 

解答 


"心 '。厂… 





，莺问 吻匈題 


% 


答 


你巳经看过儿次了，当你察觉程 
序代码重复 的可詭 性时.应该考*封装. 
在此例中. 极设上 （ serve) 圣代冰淇淋 
( Sundae ) 与上 （ serve) 秘尚冰淇淋 ( Cona ) 的方式可 
齦不太 一蜉*很合理的. 

因此，你■以41建一个新 4. 叫 W : D * aa * rtSarvic «. 
并 i 把 a _ rv «(> 方法放进该类。接着，所有的 
Dessert . IcaCraam ^ Topping 类都能 fi | 单地 J | 


<5 埒 多《，》«(>*现 ft 沭 (5 备紗.我 

物«装起來 ■ 

代 *5 故存-个祕方邮祥-一" 

ffi 如 1 :谢#•的 A 枝有变 .我 
们就不这费类。 

»1 DessertService . serve (), 假如 serve (> 改变，你 
只要在—个地方史新 tf 序代 妈： DessertSarvice 

所以.你将可能变动之物封装起来- S »* rv *<) 方法 

里的《序代碼，同时也确保每个美只有单一的改变《由. 
真的*一举两得 | 

^ :你怎么知道要将 serveO 方法从那些不同类里封 
装出来？我不*很懂《 






问》与 答案* 







回到 Rick 的搜索工具 




你现在已经准备好处理 
Rick 的不灵活的程序代码。 

你 Li 经学到了 •些新的 oo 工具与技术， 
确•久: tl 经准备 4f N 到 Rick 的软件，让它更 
具灵活性.在你完成的过程中，你会用到 
在 OO 大灾堆中所7:到的毎•件亊，也 U； 
改变 Rick 的应 用程 印变得简单。 


00原则 

将 ifti * 封浆 起来。 

对捿 o 追码， ffi 不蛊对实现。 
s sa # 中的毎-令* 只有- 令改*的 1 **。 


4三个_1*曾,， 
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给你的软件 
30分钟的伸展操 



你曾经希望你的软件再多一点点灵活性吗？当你遇到变 
更应用程序的 N 题时，很可能意味笤你的软件需要更有灵活性 
(flexible) • 更具复原力 (resilient). 为了帮助你扩展应用程序，你将 
耍做 -些分析，.堆设计并乱学习00厣《1|如何降低应用程序的耦合度 
(coupling) „圾后，你会看到较高的内聚力 (cohesion) 如何帮你降低 
稱合度 • 听 起来衍 趣叫？ WfilK fji , iJ: 我们回头脩正那不具灵活性的 
应用程序。 



Rick 的搜索工具的问题 


诊到 Rick 的搜索工具 

满典 ft 新的 OO 原《1|.我们已经准备好让 Rick 的应 HI 程； r •变 得设计 
ft 好 RWff 灵活性.这31垃我们当时典开的地方，还有-•些我们找 
到的问«: 



iitf ft 味3构 it * 數以外利乇 
他*. 个4处…… * 

£,衿*-个味8*«部必* 
: d &_ 个. 
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良好的设计活的软件 



知 5,, “”*"吻*<：的由子类。 
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Frank ： 是啊.那是个痛处，但我想不出用什么办法解决 
它。 我们必须让 Rick 的客户以某种方式捜索到不同类型的 
乐器. 

Jim : 我还是不明白为什么不能只有一个接受 
InstrumcnlSpec 的 searchO 方法。那不是会; fc 除掉所有版本 
的 searchO 方法吗？ 

Joe : 嗯，它会的，但我们还没有办法返回不间类®的乐 
器。假如客户提供 GuitarSpec. 它绝不会去比对 BanjoSpec 
或 MandolinSpec, W 此，从 searchO 返回的列衣总珐只有与 
其户规格相关的乐器类型。 

Jim ： 因为我们不能实例化 InstmmentSpec, 对吗？它是一 
个抽象类，因此我们必须创建 MandolinSpec, GuilarSpec 或 
其他 子类。 


Frank ： 那也是一个问题……此外，我们是不是应该对 
类似 InstrumemSpec 的接口编码，而不是对 GuitarSpec 或 
BanjoSpec 这类实现编码？ 

Joe : 嗯……我没有想到这些，不过你是对的。我们真的 
应该把焦点放在接口上，而不是那些实现类， 



良好的设计 = 灵活的软件 


仔细醮 slsearchO 方法 

看来好》很请楚.我们为 Rick 的客户处理搜索的方式有 H 租。我 
们可以把 Instrum « ntSp«c 变成实体类，俱那会解决我们所有的问 
* S 吗? 







前进到非抽象的 InstrumentSpec 


分析的好处 

让我们采取把 In«t r _ n tSp« C 变成实体*这个办法，屙肴 
它是否能为 Inventory 的设计带来任何好处. 

public class Inventory { 

private List inventory; 

public Inventory!) { 

inventory = new LinkedListO; 


public void addInstrument(String serialNumber, double price, 
InstrumentSpec spec) { 

Instrument instrument = null; 
if (spec instanceof GuitarSpec) { 

instrument = new Guitar(serialNumber. price, (GuitarSpec)spec); 

I else if (spec instanceof MandolinSpec) { 

instrument = new Mandolin (serialNumber, price, (MandolinSpec)spec); 




Inventory.add(instrument); 


public Instrument get (String s 
for (Iteracoc i • i 

Instrument instrument - (Instrument)i.n« 
if (instrument.getSerlalNumberO.equals! 
return instrument; 




. 现在罨起 * i? 多 3 
叛本 . MtJnsttumeniSpec~ 


public List search(InstrumentSpec searchSpec) { 

List matchinglnstruments = new LinkedListO; 
for (Iterator i = inventory.iterator0; i.hasNexci); I 
!nt instrument ■ (Instrc 





«««<■() 

珑乜 辟合的沙 b . SF 
值 t _4 列表中®舍不用走轚的沣 s . 
釦*;島一把憂坨林， 
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再多做_点分析 - 


尖你的铝 I 


SearchO 方法不是唯一一件令为 Rick 的应用程序增加新乐器困难的 
事， 你还必须为毎一个新乐器*喟增加新的 Instrument 子类。但这 
是为什么？让我们再多做一点分析吧. 


为什么在 Rick 的应用程序中需要 Instnimem 类？ 


什么东西是所有乐器共 N 的？ 


什么东西是乐器之间不同的？ 


假如你有任何关于如何可以改变 Rick 的应用程序，让你不需要所有 
乐器特定的子类的想法，就将那些改变加注到下面的类图中。尽管 
增加或移除类与特性，由你决定如何改进 Rick 的设计， 
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改变的阻力 


4 尖你的铝？ 
解答 


再多做一点分析…… 

SearchO 方法不&唯- •件令为 Rick 的应用 
程汴增 加新乐 器闲难 的杯，你还必须为每一个新乐器类型增加新的 
liismimem 子类，但这是为什么？ U: 我们再多做一点分析吧。 

为什么在 Rick 的应用程序中潘要 Instrument 类？ 



你鰣 S 的不糞爱 
龙全耷残们的爸 
索柏阕. ( SiS'i 



绝大多 数的乐 BS 少布几个 W 目的特性.■乌价栳。 
Imtruweht 存锌达目的 特性.然后毎 一个特定的乐器类 
型玎* Instrument 扩展。 

什么东西是所有乐器共同的？ 

序吾.价格 格（印 «对 不 a 的 乐 s « 型 at 并 螫 a 格 
的麵节玎能不《> . _ 

什么东西逛乐器之 问不 ㈣的？ 

規轎：鬌 ■■个承 》»8»+« 縛 fct •不 W ■的 tttt , tfB . B 为鬌_#乐 
■省不 BWlMtninwirtSm , »»筹-#乐_»布不神 


fly 如你有 ftM 关干如何吋以改变 Rick 的应用程序，让你+需要所有 
乐器特定的子类的想法，躭将那些改变加注到 T 面的类田屮。尽管 
增加或移除类与特性，由你决定如何改进 Rick 的设计。 
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烫仔细 M 看乐器类 

即使 ••• rchOfle / t ； 起来比较好，伹所有的乐器子类以及 
Inventory 中.的 addln » trumant () 力•法还是仓 - 叫实 IW ; 的 N 
题。 

Id 住，原+：我们 ihlnatrunwnt 柚象化，是因为毎种乐器类 
增由一 个子类 表示： 



然而类实际上兵系到行为 f 

但你创 as f - 类的押.山通常足因为® 1 ••类的行为不 m r -其 父类. 
在 Rick 的 Vy: 用 R 序屮. Guitar 的行为 J-Instrumant 的行 
为吗？它在应用程序中运作的//式不 Mandolin Jt, Banjo 
吗？ 




^ SH “ m0ft 

h»U()ii 枓的行妗。 



iiti^OO»t'). ««** 

■檐 

j * 闲 8 ,' 糾-食几：我 
们含《1床«这个闲杜的 


1. 因为 Instrument 类代表的是一种概念，而 
不是一个真实的对象，它实际上应该是抽 
象的，所以我们必须为毎一种乐器类型准 
备一个子类， 

2 . 毎一 种不间 的乐器焚喟都有不同的特性并 
且使用不 M 的 In » trum « ntSp«c f - 龙，因此 
我们擗要为毎•种乐器类型准掩•个乐器 
特苻的构造函数。 


这些符起来似乎是相当好的理由 （好吧 ，至 
少第一个是），但&我们最后会有一大堆没 
做什么事的额外类，那会让我们的软件没有 
灵活性而且难以改变.那么我们该如 H 做呢？ 


ii*8 来体 4 *_个 
■•吋 ftSErttS. *不4的 
Ho~ W 例孑 . ®rtii 
# 0係轉 J"* 11 * 11 "*" 1 袖象 


曲 j^Ricfc 的在用 ® 

汸破 栌奉 （体*•欽 
碑的》 一歩）.我 


记住第 1 章里编写伟大软件的 
第二个 步骤： 
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5^尖你的 




面向对象原则来营救！ 

Rick 的应用程序确实有问題，俏不确定是什么问埋。当你不知道解决设计问埋需 
要做什么时，就査看一次你所知道的00原則，看看它们当中是否有哪一个可以 
帮你改善你的软件设计。 

对于下面毎一个原则，假如你认为它可能有助于解决我们的问题，就将它勾选出 
来。由你写下使用该原则的可能方式来改善 Rick 的捜索工具的设计。 


( □缝承 

(Inheritance) 


O 多态 

(Polymorphism) 


Q 抽象化 

(Abstraction) 


D 封装 

(Encapsulation) 




磨刀 S* 向■•问 《- 


4尖你的铝 I - 

、、解答 

面向对象原则来营救！ 

Rick 的应用程序确实有问题，但+确定是什么问哩，当你不知道解决设 I 十问题 
需要做什么时，就査舂一次你所知道的00原則，看看它们当中是否有 W —个 
可以帮你改善你的软件设计， 

我们 B 经将 M 承运用在 Instrument. InstruwentSpec 乌它们 的孑类 
» o fS 乐 8 持 定的 孑 jT^7¥»~i»istrui>ieHt 佴没 ftH 7 

■&» . «« 不^ « a &» 。 — — 

我们在 search!) 方法中《用多6,栴所«乐8视为一个 lostrumeMt 
实供， B 不去》心它们 HWUI 

简*多 addlmtruwe«t() 上 »B 栴一«£ 
氯出投的《•代《_離. JMHab»3 . ~ 

IhitruwctifSpte je 其子籌一令乐骤的羡轎麵笮从 liutruimwta 享 
身》取出來，》«»们缯加斯的乐 》w 性 g 不金彩 墨碥的 
lnstr«went 类。 — __ 


(Inheritance) 


多态 

(Polymorphism) 


Q ( 抽象化 


(Abstraction) 


5 tsg 泠玎认 ffi 得 g 多…… Ktt . 

之物！ ©为 f 一种乐 8类型的««正是変化之 粕，我们陡不锭认 
某 种方式 栴邶 完金从 Instrument A iMStruwewtSpee fit * 






















让坏设计去死吧 


设计 之死（决策） 

你将而对的 JftW 难的事 W 之一，就迠摒宑你自 d 的 
设 I 十所犯的错误•在 Rick 的拽尜 I 具里， 为铖•种 
乐器* 喟准务中.独的 iMtruiwnt | •.类汴不合理。然 
而它花了我们近30页的篇幅（以及第5莰的两个部 
分） 才想出来，为什么？ 

因为 当时它似乎很合理 ,而且改变某件你认 
为已经运作正常的事是 很困难的 ！ 

编码一次，査看两次（或更多 次！） 

^^当你遇 到问® 时，持续査看你的设 
计。你稍早作的决策可能是现 
任让你头痛的原因。 


解 析別人的程序代码很 ra 申，但你必须学宥肴你内 
己 的程序 代码并 R 把 M 题找 出来。这也垃 M 级 if 审 
(peer review) ——请一些程序设计师间伴-•起希肴 
你的程序，能«正帮大忙的地方。別担心你是否潘 
要改变，设计较佳的应用程序长期下来会帮你省下 
大量的 时间。 

设计是 反复进行 的 ( iterative ) ……你必须 
愿意 改变自己的设计 以及你从其他程序设计 
师那里所继承的设计。 

自尊心扼杀良好的设计 

I 別害怕査看自己的设计决策 

: 及改酱 它们，即使那意味矜 
: 4i ® 1 进度例退。 


愿它安患 

乐器特定的 
孑类们 


我们会怀 A ■你们 的 
(*•6. **■*.»**) 



让我们未达终“.⑽ 8 ” 
的孑奕的外*鼕. 爲-次 
鏟鰱鵷 s 体太 软蜱" 
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将坏的设计决策转变成好的 



我们 " f 能也盅要在每•种乐器屮增加新特性，让我 
们知进它是什 么类® 的 乐器： 


instrumentType ^ 


serialNumber: String 
price: double 
spec: InsIrumenISpec 


getSerialNumbert): Siring 
geIPrice() 


.<): double 
iffloat) 

InsIrumentSpec 


InstrumentType 

I toSIringQ: String 


H -个傳 Wood 务 

驊样的枝畢奕轚。坪 
么.现在* 坩知- 种軔乐 8S 
&金 <*« 的 * fc 枚聲炎《坩加- 

个析值•/ 


ban, 0 ^<vwmooc. 

軌 H (iflifk 


'光 icifli 的 C £ 



• k 


.r, . 247 





爯一次小组会谈 

(认及一些采 t 川 I 的帮助） 




. » il1 - 6 

如何 e 6 ifl Ric) •的在 
用《存的9法- 


Joe ： 但我们已经那么做 f …… 我们让 Instrumem 变成实体类并 
去除所有乐器特定的子类。 


Jill： 辜实上，我想那真的只是第一步， Rick 的应用程序里真正 
的变化之物是什么？ 



Rick 的 S 用《序 中的変 化之》 
是 ft 么？ 


在 d tf 空格 
TCf.il. 
办的 t 化 Z 


Frank ： 我们已经讨论过这一 点：毎 -种乐》的特 性即是 变化之 
物。 


Jill ： 所以我们能以某种方式封装它们？ 

Joe ： 我们 已经 做了： 我们为此使用 InstrumeMSpec 类。 

Frank ： 令一下， Joe, 我们使用 InstrumentSpec 是因为那些特 


性同时被客户与乐器用到，所以那是与重 S 程序代码比较有关的 


Jill： 没错！那就是我的重点……在 InstrumeiMSpec 里的特性也在 
变动，因此，或许我们需要增加另一层 封装。 


Joe ： 那么，因为毎•种乐器的特性不同，我们应该把那些特 
性从 InstrumenlSpec 里抽出吗？几乎 就像是 双封装 （double- 
encapsulation) 或之类的亊情。 
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Jill ： 有一点……我们从 Instrument 类中把不同乐》之间共间的 
规格封装起來，然后再从 InstrumenlSpec 类把变 化的特性封装 fe 
来. 
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Rick 的软件中的 

让我们苻#既冇的那-垣封装， 
些封装.将那些变动的特性从 
抽出， 


‘‘双封装” 

然后肴#如何洱增加一 

InstrumentSpac 类中 


不4-个 00 地 

用㈣ ⑽你.巧今方 *.) ㈣ 

«.«o 



因为 这哼特 性的某一些在变化，所以我们想把它们 
移出 InatTUMnUpac 类.我们需要-种方式引用 
这 些特性 与它们的值，却又不想让那《?特性被写死 
A InstrumentSpec 类中。有什么办法做到这一点？ 


逯过封 装变化 
泛物，你 it 应芹 


你想你能使用什么类型表示特性吞 




fl 达问其值，侄义不必为3 支特新 ^ 

特性 35 改变你的 InstrumentSpec ? 


249 



动态处理乐器特性 

在上结甩处，你想到了什么可存储特性？ 
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我们刚刚傲了 什么： 烫仔细 Mf 

任何 时候你 flSL 变化的《；•物，你应该找个方式进行封装。在 
Instru ». ntSp * c 的例 f 中，我们知进乐器的特性在变化。 



当你有—徂特性烤对象实化时，谀芹 
穿令 ( collection ) ,傳糸动迄 
吝慷抑些:特性„ 

侪将少你的粦中移餘许多方法，并夂 
在新特性衹芹栈序时绝免改实 
你的移 序代碚 《 


当前位霣 ► 251 
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程序代码磁铁_ 

使用 Map 存储特 性似乎 是个好主意，但是 It 我们看看，一旦实际为新版本 
的 InstrumentSpcc 编码之后，亊情肴起来会如何？你的任务坫使用仇•面底 
端的磁铁来完成 F 面的程序代码， 

import java.util. _; 

import java.util._; 

import java.util._; 

public class InstrumentSpec { 

private _ properties; 

public InstrumentSpec(_ 

if (properties == _ 

this.properties = new 

this.properties = new 


public _ getProperty(String _ 

return properties.get(_ )； 


public _ getPropertiesO { 

return _ ; 


public boolean matches (. 

for (_ i = otherSpec.. 

i-_(); > { 

String _ = (Strir 

if (!properties.get(_ 

otherSpec.getProperty! 
return _; 







.0； 



新的 InstrumentSpec 类 


B 


程序代码磁铁解答 

使用 Map 存储特性似乎是个好主意，但是让我们看#. •旦实际 
为新版本的 InstrumentSpec 编码之后， 事 悄呑起来会如 H? 你的 
任务是使用贞而底端的磁铁来完成卜'面的程 It •代码， 
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1^1 : 现在. Instrument 与 
InstrumentSpec 都是实体类？ 

: 是的. Inslrument 不再只是 

橛 念，它代表 Rick 的鼻存里的实际乐 
器。而 InstrumentSpec 是客户在 
搜索时用以传送规格的东西，也是 
Instrument 用来 存錄乐 器特性的东 
西. 

: 能移除我的 Guitar 与 

Mandolin 子类吗？ 

• 是的.还有 Banjo , 
Dobro 以及你 刻建的 其他乐 B 种定的 
Instrument 子类， 

I ®): 那是因为我们现在直接使用 
Instrument 类吗？ 

^ : 是的！记住，你通常是 

因为行为有变化才刻建子类。在 
Instrument 子类里并无行为的变 
化。 事 实上，我们为每一个乐器子类 
所做的一切只是 胡建新 的构造*数„ 
仨这却增加 T 许多类，减少了应用<£ 
序的灵 活性. 而且实际上并本帝给我 
们任何有華助的功能。 


1 ㈣ 灼匈 @ 

1^1 : 我理解去除 Guitar 与 

Mandolin 这件事.但对于我们为什么 
不再霱要 InstrumentSpec 的不同子类 
感到困«。 

^ : 没关系•那 是整个 Rick 的应 
用《序设计中最 球处理 的部分之一。 
记住， OO 设计的关鍵碌《之一就是封 
装变化之物.在 Rick 的应用 C 序里， 
每种乐 S 的特性都有差异，所以我们 
将那姿特性从 InstrumentSpec 相 
出，4把它们放进里，现在. 

S 你增加另一个具有新特性的乐 
»时， T 以只*将 新种性 增加为 
properties Map 里的名/值对 .. 

1^1 : 越少类*处理.软件就越炅 

活？ 

^ :在此洌中•是的。但确实有 
些时候增加类会让你的设计更灵活， 
记住，增加 InstrumentSpec 类有助 
于将乐器与它们的特性分开，那是很 
好的 • 然而在本 幸中. 我们一直在移 
除类. 那使得增加新乐器列 Rick 的软 
件中变得比较容易， 


I ®1 :我从未想到不需驀为乐器与 
其规格准备子类.我该如何养成这种 
观念并变得精通此道？ 

^:精遢软件设计的最任方式就 
是編写软件！在 Rick 的应用 C 序里， 
我们必《走过一些错*的路，像新增 
Guitar 与 Mandolin 类. 才徒想出真 
正需要做的事情为何。 

大多数的好设计却是从坏设计来的， 
几乎没有人在*一次就 範全部身对. 
因此做你觉得合理的亨，然后开始运 
用你的00摩«与设计櫈式来看看是否 
能改善你所完成的事. 

祈杯玫计芮弗 


>要害怕犯铐 
及欤变。 



完成 Wck 的应用 程序: 
lwstrumewtType 枚举类型 


我 们几乎 已经完 成了一 大半，让我 们仔细我们的新设 
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当前位鑒 ► 25： 



禮! Rick 的 異有炅活性 的应用程序 

我们已经对 Rick 的应用程汴做了 I 午多改变，很容易躭会忘掉我们一 a 
努力的方向 • 然而査 fi •下下而的炎图，否屙阳冰的应用程序 现在有 
多卿. 



第5章 （第 二部 | 
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但应用程序实标上运作正常吗？ 

Rick 的软件现在看起来比 本隶一 开始时好多了——当然比 我们为 曼陀林 
与班电琴等准洛•堆子类时看起来好多了， m 我们还是必须确认搜 VKT 
具 麻的能 运作！所以让我们钯新测试类，并11#屙新版的 Rick 的软件如 
何进行捜索工作： 


_ 


Findlnstrument.java 


public class ( 

public static void main(String[] acgs) 
// Set up Ric^s i 
Inventory i 

initializelnventory (inventory); 






Map properties = new HashMapO; 
propertias.putC'buildar", Builder.GIBSCMl); 
properties.put{''backWood", Wood.MAPLE); 

InstrumentSpec clientSpec = new InstcumentSpec (properties); 

List matchinglnstrumenCs = i nventor y. search (clientSpec); 
if (imatchinglnstruments.isEmptyO) | 

System.out.printlnr'You might like these instruments:"); 


我们戏沾值用 
JnsttumcntSpffc 冒的 
N\, V . fS 现在祐 ■违场 



it.println("Sorry, we have nothing for you."); 


思 3 经公 j{(2 

67. 


// initializelnventoryO method here 


-r 二 ur: ， 二 ‘ 

任下 _5 做这件搴 " 





new InstrumentSpec(properties)); 

// your code goes hare 不 


，: «曩 知进 diA 的瓖疼的吉> * Nv. 、 I 

private static void initializelnventory(Inventory inventory) { 
Map properties = new HashMapO; 

properties.put(''instrumentType", InstrumentType.GUITAR); 
properties.put ("builder", Bui lder .COLLINGS); 
properties.put ("model", 
properties .put rtype". Type.ACOUSTIC); 
properties.put(•'numStrings", 6); 


Findlnstrument.java 


—雜 #*1# - 

为新版的 Rick 的软件运作得垃否 正常， 我们泔拽尜.下吉他及其他乐器。你 
的任务&编" QFindlnsirumem.java 中的 inhialiMlnventoryO 方法，增加一些吉他、变 j 
陀#与班申-¥到阳4的 库存。 下面，我们列出 RickS 前有的乐器，甚至写了一点程! 
序代码来增加第•把吉他，佾你起个头. 


i Gibson F5-G acoustic mandolin, 
: Maple back, sides, and top. 

Serial #9019920, for S5495.99 
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谢试躯动 Rick 的 
设 i 十良好 的软件 


务必确定你已经把上页所示的所有乐器邯添加到 


Findlnstrunent.java 里的 initializelnventoryO 

方法中， 接笤 编译你的类。现在，你已经准备好测试 


Rick 的软件…… 

……好吧，是几乎准备好了。首先，你需要想想基于当 
前版本的 Findlnstrument 的搜索应该返回什么。这里 


心 ㈣ 



班卓 


V. 



® 下饬认妗 棵典 的虡存注 



〜 利农分 大赵浇 


«序««含我到的竦 8 


当前位 霣 ► 261 






雜翁 

为 i* 看肴新版的 Rick 的软件运作得是否正常，我们得搜索 • F 古他及其 
他乐器.你的任务&编写 Rndlnstrument.java 中的 iniiializelnventoryO 方 
法.增加一些吉他.«陀林与班 卓琴到 Rick 的库存， 


private static void initializelnventory(Inventory inventory) { 

Map properties = new HashMapO; 

properties.put( M instrumentType w # Inst rumentType .GUITAR); 

proper ties.put (''builder'*, Builder.COLLINGS ^ — ； -- - 

properties .put (''model", | Collings CJ 6-string acoustic, 

properties.put (''type". Type.ACOUSTIC); { ln dian Rosewcrad back and sides. Spruce 

properties.put(''numStrings", 6>; | top. Serial #11277,for $3999.95 

d". Hood.INDIAN 


a f) .«• & 
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Rick 的软件运作 正 常， 
他的窖户荻得三种 选择: 



Ricfc 的客户 




%java Findlnstrument 

You might like these instruments: 

We have a Guitar with the following properties: 


numStrings: 6 ° 坌户的。 

You can have this Guitar for $2295.95 

We have a Mandolin with the following properties 
topWood: Maple a 

backWoo d:CSaDtfe^ — 木 ** 

builder:CGibsofi) r 的 Qi6«o”l 陀林 也符 

朴，■■瓣 

You can have this Mandolin for $5495.99 
We have a Banjo with the following properties: 

系木 * 背的。如时乐 丨 … 

type: acoustic --— 把班丰 #, 班丰馨 :_ 4 有饔 

model: RB-3 Wreath « 木 «. 不过迖 沒有兵 系， 

numStrings: 5 

You can have this Banjo for $2945.95 


is « f 的符合 Bt> 仙 


—— V lS) 、 

I®) : 我的输出跟你的不哪里错了吗？ 

^ : *1 如你的版本的 Rick 的搜索工具返闽不约的吉 

他.或諭出相同的吉他.但具有不 W 特性. 么你应该:确 
认在你的库存 i 的乐》与我们的是5柚岡.捡查一下* 
260) [上 的钵 习以及 *260 到261 K 上的答*,并确认你在 
Rick 的库存里的乐 R 与我们的相同， 


I®): 这真的是好测试吗？因为我们只有 一把班 卓琴与 
一把曼 陀林。 

: 问得好，你是对的.再多准备一*班+琴与曼陀 
林.以真正确认 Rick 的搜索工具只挑出符合要求的班車琴 
与曼陀林会比 较好，抽飧加 入一*不符合要求的班車琴与 
曼陀林.并试着以其他乐》 測试 Rick 的搜索工具， 
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当荫位置》 265 


变更容易性的大挑战 


改变 Rick 的搜索工具有多容易？ 

咱们再为 Rick 的应用程序添加对 dobro 吉他句小提琴的支抟.我们稍 
早在第5章的第一部里曾经试围做这件事，伹它变得-闭槽*这一次 
事情会变得很容易，对吗？下面是当前版本的 Rick 的软件的类图。 



第5章 （第 二部. 
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为我们的软件做变更容易性 （Ease-of-Change) 测试: 


O 支持 Rick 的新乐器类型 耑要增 加多少个类？ 


• €电2仿的政4 有多瑢 
农妨的*值方式 


O 支持 Rick 的新乐器类型需要改变多少个类？ 


O 假设 Rick 想开始记录乐器的制造年份.耑要改变多少个类 
以记录这项新位息？ 


O Rick 还想增加新特性， neckWood, 来£录乐器的颈部 
(琴颈）使用什么木料。需要改变多少个类以支持这个特 
性？ 


答《見第2«« R, 



改变 Rick 的捜索工具有多 容易？ 

咱们再为 Rick 的应用程序添加对 dobro 吉他与小提琴的支持.我们稍 
罕•在第5章的第一部里曾经试图做这件事，但它变得一团糟.这一次 
事情会变得很容易，对吗？ 

为我们的软件做变更容易性的 测试： 

O 支持 Rick 的新乐器类型需要增加多少个类？ 

半个期设〖我们 BK 去»» 布乐 BW 定 WlmtruweHt 
鸟 ImtruiMHtSpM 孑类 . _ 


O 支抟 Rick 的新乐器类暫耑要改变多少个类？ 

-令：我们 *粟新增乐 tIKSS IwtnwiarfTyiw 枚 
»类型 。_ 


O 假设 Rick 想开 始记录 乐器的制造年份，需要改变多少个 
类以记录这项新信息？ 


半个》没〖你玎《■将乐 ■的 wa 年份存在 



O Rick 还想增加新特性， neckWood, 来记录乐器的颈部 
(琴颈）使用什么木料。需要改变多少个类以支持这个特 
性？ 

最羞的 H 况 Tit- 个，《许_令》不纛粟| BMkWood 
穴是«们»與餹在_抑打11瞩《11找^«中的||^^1的男--个 
Wtt ……0成许霣们纛籮缯加_螫本》的枚拳值利~ 
Wooiltt»ieg! 中。 
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良好的设计 = 灵活的软件 


太#了〖我们的软件1容易变 E 的…… 
但兵子“沟聚性” 一攀义如何哝？ 


你的* 两搴 电 
饮 4 W 内»力《« 


•t ■部炎的名坊-耷 * 
•!，• <«><5个 HI®* •不 
H •&也 符羼子》_个 


A cohesive class does 

one thing — 

really well and 
does not try to 

do 

or be 


something else. 


* 的*趄 

r ± ntini 我们的 
• J ""«°*»itRi£：iR.c*e 54 
存. *7 4 ff 名木钭 g 用 

神的規格： 


ff 後* Ai _ s *« 么本 
科4<5蛀的它* 

' ,#. 汝在》8 杓椹 达土 . 
g 不 &g<a_A° 


- 

内寒力， cohesion ,, 由奪力罨皂淳一樓块. 类或3$彖内 
备无薏 t 问的 连戏度 (debtee ot co ”” ecdvity ) 。致件 
的内寒力赵婁.在用 枝序中 S 个类的贵仔舦定义得起 



妨 fl 起和兵 ( wctt — deiintd And ttlated ) 0 备个 
类軚 fi 有«定 一 组紫密相关的 im 塞执行。 




具内聚性的类把焦点 放在一 件事上 


沟聚力认及类改耷的 
一个理由 


你或11••不理解内 聚力， 但我们已经在这本 ts 中谈过它了， 
还记得这个吗？ 



内*力确次坫应 用程序屮 类的功能冇多紧密相关的-种 ft 
度。 假如一个类由完全相关的功能组成，它便只有一个理 
由去改变……这蛙我们在00大灾难中所谈过的寧。 

这里是当我们确认毎一个类只有申/ -理由去改变时所谈到 
的一 些类： 


基-个衆的功 tt «4 金夂农 
碎的 : ， s _ 个®4«<5*度 
内 Urt 的 it , ( i 值饵它容务 
ti . 乞|诂总》他类的被 
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良好的设计 = 灵活的软件 


% 


: 那么.内聚力 （ cohesion ) 
只是一个代表应用程序有多容易改变 
的花哨字*? 

^ : 不尽然.内聚力把焦点放 
在你如何构建软件中每一个单独的 
类.对象与包之上。 极 如每一个类确 
实只做一些同性 瓊的事 •. 那么它可能 
是具有高内聚性的 tt 件片段，位是假 
如你的类做的是各种不是 K 密相关的 
事.坏么你可能具有&内聚力 (low 
cohesion). 

I ®) : * 么.具有离内聚性的 

(highly cohesive ) 软件是松散«合的 
( looselycoupled ). 对吗？ 

^: 正碥！几乎在所有的情况 

下.你的软件越具有内聚性，类间 
的挺合就越 松教. 在 Rick 的应用《序 
中， Inventory 类真的只关注库存 
的管理，而不是乐器如何比对或什么 
特性被存《在乐 S 的规格_£。这表示 
Inventory 是具有高内聚性的类.也 
表示它与应用《序的其他部分是松教 
林合的.例如， Inatrumant 类的改 
t 对 Inventory 类没什么影响. 


1^1 : 但是所 有这一 切都代表该软 
件容易变更.是吗？ 

V : 大部分时候是的。但是 

还记得我们在本幸一开始邪个版 
本的 Ricii 的应用程序马？它仅仅支 
持吉他，甚至没有 Instrument : 与 
InstrumentSpec 类。这是内 
聚性相当高的软件—— Suiter 与 
Inventory 松合.然而，我们花 
了很多工夫才让它支持曼陀林你 
从根本上改变应用《净所做之事，像 
从只*一种乐 器到* 多种乐 8. 你 T 
能还是得为*本已《具有内*性及松 
散耦 合的设 计做很 f 改*。 a 此内聚 
力不总是软件有多容《■改 t 的一項指 
标， （* 是在你并表大《改变杖件如何 
运作的情况下.高内聚•性的软忤通常 
是客易改 t 的。 

1^) : 那么高内聚力优于低内聚力 

m? 

^ : 是的。在良好的 oo 设计 

中，软件的类与 櫈決只 做一件基本的 
事， 而昱真 的把那件亊做得很好.类 
一开始便做两三忤不《的亨.就 TII6 
脱离高内聚力以及良好的 OO 设计. 


I®): 具有内聚性的软件是不是比 

较容易重用.就像变更 一样？ 

^:答对了。高内聚力与松散《 
合意味 着软忤 容易被扩展，甚至被分 
解与重用，0为软件里的所有对象不 
会交互依#9 (interdependent) 。 

这 样想： 应用《序中的内聚力越高， 
每个对象的工作就被定义得越好。对 
象 （及其工作） 被定义得越好.就越 
溶易 将该对象从一个情境 （context) 
中舳出，然后在另一个请境中做《样 
的事。该对象会很高兴》埃做它很 
特定的工作，而不论它在何处被使 
用到，这就是论*中■■无入而不自 
得”的意 .5. 

: 通过这一整章.我们 一直在 

让 Rick 的应用程序更具有离内聚性. 
不是吗？ 

^ :大部分是的， <e 是让我们史 
仔细看这 个问题 … 
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珙计生命阀期 


当前位置 ► 273 











伟大的软件通常就是“够好” 
的软件 

知道何时停止设计软件足一件困难的事。 
当然.你能确认你的软件做它应该做的事， 
然后开始提萵它的灵活性 *5 内聚力。但是 
接下来呢？ 

有时，你就足必领掙 Ik 设讣，因为你已经 
用尽了时闽、金钱，有时.你躭是必須认 
清你已经做得够好.可以继续往 前走， 

假如你的软件运作正常.客户高兴并且你 
已经尽力让它是设计良好的，这时可能就 
是移到 r -个项 b 的时候 f 。 花时间编写 
••完美软件”只是浪费时间，而花时间编写 
伟大软件，然后往前走，必定会帮你寂得 
更多的业务.提升以及大畐:的金钱与赞赏。 






00 A 邡 X 典箱 


r 哇！自从我们开始回头修改第1章的 Rick 的应用程序，你实际 
上已经走了一段很长的路。你己经学到许多关于设计的事.因此 
让我们快速复习一下已经加到你的工具箱中的工具。 


下学«的*_件摩 


好的電求磘係你的系统如 
铕期 《 p 样注<1。 - 

磘认你的索 求洚籯 ■? 你巧 
M 奄用例。 

诠用伢的用剜我出審户忘 
饬的辜， 

伢的用例将描 s 仔何不劣’ 
漼的* 求. 饬巧拥 髴《料 
进饬的系统中。 

饬的 f 求坍免4陆«时用 
(AA 衣）。 


一 分种岛设舛 

设分农好的炊4容易殓变島护果。 
值用 薄扣装 岛链承这祥的基本 00 
琢的来 《1 係你的炊件有炙法伐。 

它！ 别島《说分 甚桫. 印值邳 * 

& 的 tf 设并.1汝就甚《汝。 

SliX ■你的个类部只奄内** 性： 
莕一个 Jtlp 在找擘该存把一件搴 

链« ft 件的设升法命燭朗的暴孖 • 
, s 抬玆努力栊赛内荦力。 


由 •松 
合的故件， 


00原則 


«t«c 物«装起来。 

对戏 Ofll 砝. 》不4对*现， 

6用《4的 S- •个*. 0 .有_个《由电4~ 
*4 关子行 衿岛功 抽的。 


(I "00 太灾蟢“ 岛这 _ 
、 SCI ®. 我们坩知5几 
' 个扣的00 承时 Hi «葙 
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it 


填字游戏 


这个字迷特別难，几乎所有的答 案都打 •点难度，并 R 横 
跨第5抚的两个部分 • 祝你好运，让你的左脑动起来喔！ 



橫排提示 

3. Never code to this if you con help it. 

8. Sreot software is easy to_. 

12. Software that's easy to change is 

13. Do this to what varies. 

15. Never be afraid to do this to your designs. 

17. This will kill good design. 

18. Classes are about this. 

19. When one thing is made up of another. 


4. Abstract classes 
UML class diagrams. 

a class inherit 


5. When a cl< 



class. 

6. This ¥ 


is the type of group ensuring your 
software was highly cohesive. 

7. Apply these to add flexibility to your 

9. Cohesive classes do this really well, 

10. Don't be afraid to do this; <t will help ya 



答对了吗？ 


蘚答 
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6 解决大问遝 

“ 我的名字是 Art Vandelay 
我是架构师 ，’ 


真正做大事的时候到了，准备好了吗？在你的 OOA&D 工具箱里已经 
有了许多I具，但是当你必须真正做大事时，你知道如何使用这些工具吗？ 
好.你可能不知道，伢你确实已经具备处理大问题所需要的每样 东西。 我们 
即将学到一些新工具，像领域分折以及用例图，然而这些新工具都是基于 
你已经知道的事，如聆听客户以及动手写程序之前了解你将要构建什么•准 
备……开始扮演架构师（译注 1) 的时候到了 • 

►译注 I : 衣 幸中的 ■•架 构师 " ，原文为 “ architecl - ,即建域中的逹筑押.在软件工 a 中 W 作■架 
构解.软忤架构师是软件項 H 的灵蝝 人物，必《4«功》6*求，开发部*.运作性能. 

技术以及系 《■ A 活性与可維护 性等. 在有隊資*与时间下.设计出最合适的软件架构， 







大型应用程序呢 •. 
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3 . 努力宍琪可 
维铲、可重 



解决大问 s 


兵鍵在子你如何煮待大问越 

想想 IK 你如何处理大型应用程序中的大问埋？你通 
常会先体轮廓 （big picture) ,然后再开始处 
理该应用程序的•部分功能。 

看待大问题的最佳方式就是化整为 
零，为许多单独的功能片段 
(pieces of functionality )' 。 

你可以将那些片段的每一个创建为要 
解决的 单独的 问题,并且运用你已经 
知道的每一件事。 

• 0. 你让应用程序的-部分像你要的那样运作，接苕 
你就能继续前进至应用程序中的另 • ■个功 能片段.对 
毎 •个片段来说.你可以运用我们前面一宜在谈的相 
间的基本原 



4>i.) •的问辁： 


你可％将大洵韪穸 
斛成汾多功鶬片段， 
暌着鉍单独解夬每个 
片段 。 



你 B 羟知通的事 …… 

你 di 经学到很多将会帑你解决大 Riifi 的知以……你可 
能还不 足很押解。 很快 fl —卜•我们已经知 进的如 H 编 
写伟大（大5!>软件 的琳： 

逯过 封装奕化戈物, 
it 你的轸件真有炅 
活性, 冥笮易欤变。 



对按 P (inierface ) 编 
褚， 芮>是对宍琪 
(implemeniaiion ) , 


祕 象妗霈求 让你的轸件窄务 r 展。 


的最偉方式馱 
是去3斛系银 
应该够什么。 
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解决大问题 


尹祈 ( analysis ) 


这_魚« «不食喵问 址* ■ * 不 
g ) 寧食上.在用 枝存的内轚力 
(«(!«•»«) 起荛 . S —个 幼钛圬段就 
^* ii . *«0«1>)法(1邦曲0.片段也扰 


魆容 》。 

侔大软 件窄易 



改实及 r 展， 
并且侈著户要 


帮你碲保系绑鶬够 
运怍 在其宍世界 的 
幘续 ( contexi ) ^ 0 


( 分 «? K « 托 4* 言 
、 S 至 S «* * ……多 
教 t «* 下.你以■分 W 
辈 柚的功 《圬设科诒. 
纽«分《 释螫垮 
问的 





介绍 Gary 的电子游戏 


iii 个之网 S . 我们《奋下® 



Gary 的电子游戏 

远景陈述 




Gary 的电子游戏公司给游戏设计者提供—个游戏系统框架⑺咖 ^ZZ 
Framework, GSF) ,祖継邮制祕賊（邮> »棚于狐中心 
游戏 (arcade-sty.eshoo«-them-up) 以及依賴声光效果吸引玩家的电+游戏，我们 
的游戏把齡■娜诚棚狀個紅。 飾. 构 
建特定類_贼■‘瞒免秘舰 tms 躲綱 31 作陳重负担。 

此游戏系娜㈣針奸贼純麟-个核心，它狐 赌膊 的形式= 
付并具备一组定义良好的 AW, 供公司内部所有棋盘游戏 （board game) (< ♦注 3 > 
的开发项目团队使用。此框架提供的标准功能有： 

♦ 定义并表示棋盘配置 （board configuration) 

♦ 定义部队及配 S 军团或者其他战斗单位 (uni,) 

♦ 在棋设 (board) 上移动战斗单位 
♦ 判定合法的移动 
♦ 进行战斗 
♦ 提供战斗单位的信息 

此 (3SF 将简化回合制策略游戏的开发工作，以便 GSF 
的使用者可以将时间全用在实现真正的游戏内涵上。 




►烽注2: W 合 WS •略游戏， turn-based strategy game. 是一种 * 子游戏 ■的形式，所有玩 家轮洗进行. 只有在轮到《|己的 操作® 
合时才 tt 进什各种行动 • 早期的 策略游 《*• 受限于 CPU 的运算 能力， 在两及游 戏乐* 与运作《 鈮的情 况下， f 半采用 
这种形 式. 比较有名的有 <三《 志》.《天使 帝0)> . 《炎 龙骑士等 系列. 或许你认为•轮 AW 策略游戏是 
个较好的译 ifl , 然而 “ W 合制"已 S 是相 SiiW 的说法 • 在此， -M 合"一词指的是••操 作* 合 •. 也就*暑个％ 
家轮洗采取行劝的机会， 





解决大问题 


下面是一些可能要开始做的事，勾选出你认为应该先着手的地方， 


□ 跟可能使用此框架的人们 □ 编写用例. 
谈谈。 


H 尖你的铝笔 


(□与 Gary 谈谈。 


□ 收集霣求< 


□ 开始绘制类田. 


Q 开始绘制包田。 



伪的® 的- 
名 《 终 i4 只柙. 


需求与用例是个好起点…… 

从为系统违立需求列表与编写用例开始 
是个好主意。你可以《理出系统应该做 
什么，£栽你的列表，一点--滴增加功 
能……解决许多小问題便解决掉真正的 
大问题。 



……但我们目前真正知道系 
统的哪些事？ 

那个远景陈述似乎有许多关于 Gary 要什 
么的信息，但也留 _F 了许多要加以解释 
的事。 


Gary 心中想的棋 fit (board) 坫哪 .种？ 
准是 典正的客户？游戏玩家还是游戏设 
计者？所打的游戏邢垃以历史为背玫吗？ 
成#我们必须友 持像激 )t 枪 1 i 太空船之 
龙的东 西？听起 *4f» 在编写一组好需 
求之前还御很多_!»耍知 ifi. 
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解决大问题 


我们 熏要重 i 信息 

我们 手上所 有关于 Gary 的系统的东西只 有远& 陈述， 
Ifii 那根本没有告诉我们什么事。因此，现仵必须想想 
系统应 该做 什么。那么，我们应该怎么做？ 



ii-1 做 并的性 


达个系统偽什么？ 


你能找出系统更多信息的 一个方 法就是找出此 
系统$什么\也就是说，你知道有什么事情与 
此系 g 的功能或行为类似？ _ 




你巧 « C611 …… 

忖么寧的 .， 

- 达个系统不係什么？ 

你能找出系统应该做什么的另一个好方法是找出此 
系统不像 什么。 这帮你决定什么是系统中你不必担 
心的 F — 


让我们偷咁 & ary 的一个会议，看 
看我们能找到仔么。 




聆听客户 


害户的对话 


在开始动 _f- 做 Gary ® 我<|’|做的游戏系统抿架之前，我 
们® 要多 听听他和他的小组正在II •划什么. 



SrTon,, 







需要输 入《4«的命令 



Tom： 适啊， Gary 喜欢以文卞为基础的游歧。人们对里球大战之类的游戏屮 
的花哨 IS 像巳经有点厌倦了。 - - ^ 


Bethany ： 我们需要各种不同的时代 (time period ) ,可以有 Civil War 版， 

f- - World War 1版等。我敢打包®,玩家会喜欢那些历史情节。 

Susan: 好主意， Bethany! 我相信也"『以请游戏设计者创建外挂包 (add-on 
£ ft « 4 M pack) ，那就可以先买 World War H 版.然后再添购核心版本所没有的附加功 
>3 '能。 

^ - Bob: 嗯，也是很酷的卖点，假如系统支持不时段.战斗单位的类甩.制 
服、攻击形式等，我们就 "f 以把它卖给几乎任 M 开发这类游戏的人。 


Ci 4 * 

-(»»«U6ilil>) 

铣74李» 


Bethany： 你觉得我们盅®考虑非 W 史性战役吗？我垃说，我们能把系统卖 
泠设计 M 球游戏的人， U: 他们创作科幻战役吗？ 










整理功能 

对 TGary 与他的小组要游戏抿架做什么，你已经知进共多， 
那么让我们利用那些倌 A. 把系统的功能»理出来吧。 



代.邦&裘呔系诜的功妹 



Bethany： 我们需要各种 不|5|的时代 ,可以有 Civil War 版. World War I版 
I等。我敢打包票，玩家会喜欢那些历史情节。 


iaf * 不阉建* 的祕 

仏 w 4 ，个 s 


I Bethany： 坫啊。 然后我们应 该 i 持所冇类甩的地形，山帋，河川.平原 . 

地…… 

Susan： 也许还可以有太空.陨石坑.小行星或其他太空游戏会用到的东 《• 
Bob： 甚至有水_卜环境.像海草，淤泥或者其他东西，是不是？ 


侄什么功能 (feature) ? 


功能只是关于系统需要做的某件事的髙级描述。你通 
常由客户访谈中取得诸项功能（或是聆听客户的谈话， 
就*我们在前两页所做的 亊）。 


很多时候，你可以为一项功能想出一些可用来满足该 
功能的不间潘求，因此，将系统的功能整理出来是掌 
提潘求的好方法》 


法饬沒有很多鲕苷413 屢釦 

a ♦时 a ® 场 0 (如涊冲 
系垅） 很有帝 W。 






功能（来自客户） 


需求（来自开发者) 


解决大问超 


支持不罔类型 


,的地形。 

ii4 我们认謇户让鉍携的 
# - ■劝雄 



方格兵联子 (associated 
with ) 摊形类型。 



游戏设 i 十者能釗逮 I )定 
义的地形类型。 

毎一种 M 形都布其特点，影 
响战斗单位的移动。 



(<*«“《) 專致 
多个不两 wt 成 


•O 


从窖户处取得功能，接着整理 
出实现迖些功能所 t 要的霜求。 




勒尖你 的铝笔 


Gary 的游戏系统所需要的功能列表 （list of features) , 


你从 Gary 与他的小组那里取得许多信总，现在你知逍怎么把那些倍息转换 
成一组功能。 你的任务是将 Gary 的游戏系统框架应该要冇的功能填人下面 
的空格处。 
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功能或霉求' 
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解决大问题 


闲句匈題 

% 


1^1: 那么功能与需求之间并没有 I ®): 你提 a “某些人_ • 所以有 
什么大差别？ 其他方式看待功能与需求？ 


^: *. 这真的要看你问的是 

谁，对菜些人来说.功能是系统做 
的 '•大 •事.如••支持不同类 s 的地 
形，. le 是为了准确地描述功能， 
会有许 多系仗 必《做的•小"事. 
如•定义 基砝的 地形矣型”.“尤 
许开发者扩展基砒的地形典《”以 
及"允许4•个方蝽 fe 含多种地形类 
«- 等.所有这*小事都被视为需 
求.因此单一功能由多个需求构成. 
像 这样: 



功钵 4 多洚*求结合起来* 
溝足的-*■搴- ~ 


^ : 没错.许多人不在功能与需 
求之间做这样的 S 别，一項功能可能 
是“支持不 R 时代- (这是一忤相 S 
大的 事）， 另一項可 16 是•允许以水 
作为一秤地形类 《这是 一件相 S 
小而特定的 事）. 以此方式来*，功 
能与需求之间其的 没有多 大差别.因 


此. 这®人看事情的方式比较 诹是： 



以 lit 方 式来罨 .功林 
鸟 f 求笱许多 ttC 
处.个用讲多少 
9 5«44}(£用 1 . 


I ®): 那么哪一个才对？ 

^ : 两个都对！或者都不对. 

如果你喜欢的话.没有 ••哚 一的方 
式”.看待功能与需求.特别是 R 如你 
不想浪 费时间 JR 你的 C 序设计押朋友 
争执这些定义时.你最好把功 ft 与需 
求梘为你的系统必《做的事.》如你 
要把功能视* •大而鳌体"的事，而 
需求是•小而細化’的事.也无妨， 
就是不要为此争得* U 耳赤.好哄？ 



a a 




R 要玎认，就 
冬 1 拕 细节往 
后施延。 


用例不总是帮你看出 整体轮廓 
(big picture ) 。 


当你开始编写用例时，你真的是在深人系 
统应试做什么的细节。问题在于那会让你 
看不到整休轮廓.在 Gary 的游戏系统里. 
我们真的还有许多细节没准&好……我们 
正试着找出此时该框架实际 h 是什么。 
因此，即使 你可以 开始编 iJ 用例，那也不 
"T 能会你杻清：从《体轮廊的观点來看， 
你正试图构垅的东西到底是什么，当你构 
建系统时.尽可能把细节往后拖延里个好 
主意。当你在做"大 f 时， iii 不拘小 
节，别让 ••小亊” 把你 卡住。 


I 假如我们處的要为 Gary 的游戏系统编 
写用例，谁会是参与者？ 
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解决大问超 



你还是需要知道系统应该做什 
么……但你需要有一个 整体轮廓 
的观点。 

即使用例可能有点过于聚焦在系统设计的细 
节上，你还是得对系统该做什么有好的理解。 
因此，你需要一种方式把热点放在整体轮廊 
上，并找出系统应该败什么，同时还要避免太 
过深人细节， 




玎曾咁说“一穆值乎字”吗？ 

让我们看看是否能够显示 系统 
应该傲什么。 
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用例思 (Use Case diagram) 


冇时候.你潘要知进系统在做什么，但又不想深人 
用例黹要的所有细节.在这种怙况下，用例 Rl " f 能 
就& 你需要的东西， 


7 内的 #4 伙 0 ... 
相在® ⑽ W 球 = 
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解决大问题 
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把功能对应到用例田 




解决大问题 




Ip ) :参与者是使用系统的人？ 

^:参与者实际上是任何与系统交互的卟部实体（不 
必定* 人）. 在取款机的系统里.很明显地，你会以使用 
该系统的人作为参与者.但也可能会以取款机连接 的银行 
作为参与者。氙如有东西不是系统的一部分，但对系仗有 
作用.郢便是参与者. 

IpI :围绕所有事情的方框是做什么用的？为何参与者 
在方框之外？ 

^:此方擻表示系统的边界，因此你必《为方柜之内 
的所有 事編写 《序。参与者（使用此枢架的 游呔设计者） 
位于方榧之外.因为他们使用系恍， te 不属于系仗 的一却 
分. 


I ®): 我曾经看过一些用例明具有标示了 << include »> 

与《8<10如》的线条.那 it 什么？ 

^: UML 与用例图确实定义了一*方式来《明用 

W 之间所存在 的几种 关系。因此.你 T 以说一个用例包 
含另一个用例，或一个用例扩充另一个用《,昴就是 
«111(：1<146»与 « extend » 关键字的意思. 

无论如何，很容易会花费时间争论一个用例是否扩 It 这一 
个用《或者包含那一个 用例。 突然间，你又把时 间花* 
在一个方格如何支持山岳地形或一个战斗单位是否背背 
包.而不是把焦点放在较大的整体轮*上.你可以使用 
« include »4« extend » (译注 7) , < 2 它们真的不 
主郢么 重要， 这* 关嫂 字絶不应该让整体的设计洗《 "失 


l^i : 毎个褊圆都是用 例吗？ 

^: 是的.邺是用例图善于掌体轮廊的一部分* 
因： 它 A 示多个用例.以及那*用例如何共同合作来一起 
完成真正大的工作.它也帮你避免太早深入特定* W 的*# 
it (像现在，你应该担心的是 a 体的系统设计）. 


Ip ) :所以用例®与系统的整体轮麻更有关.而不是包 
含许多小细节？ 

^ : 你弄懂 T! 如果你太过担心用例叫什么或者 
是否应该在用例之间使用特定关系.便会对整体轮*失去 
焦点。用你的用 例图为 系统取得一个清晰的 10.000 英尺的 


鸟明 •图.除此之外，别无其他日的. 
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有个功能出了问埋 


- 二 H 


e - 功能磁铁解答_ 

里时候将游戏框架的功能 tj 用例围屮的用例作比对了。把毎一项 
功能的磁铁放在处理该功能的用例 上. 你能够为游戏框架中的毎 
_ 一个功能邯找到用例吗？ __ 





侄布一个功能还留着 
怎么了？- 


有 -- 个功能你可能不容易将它放置到用例图上 _■ 
仔细想想这个 功能： 它真的不是游戏设计者直 
接与系统交互或担心的亊，因为此功能已经被 
处理/ •» 


那么，这个功能如何 1 :)系统相关？涉及哪呰畚 
与者？在我们 的用例 遗 iM 什么用例了吗？ 



我们知 '个 


你认为呢？ 
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解决大问题 


谁是参与者？ 


苏格拉 (S 问答法 ( Hiil ) 


你在设计什么系统？ 

游戏框架，咄！ 

框架的要点是什么？ 

让游戏设1 十者构建游戏。 

游戏设计者是系统的参与者吗？ 

是的，我在用例图里就是这么表示的. 

游戏设计者与该框架有何关系？ 

设计游戏，我以为我们已经表示得很清楚了！ 

(有 点不 酎烦） 

游戏与框架相同吗？ 

不，我想不是。 

为什么不是？ 

游戏是完整的，你可以实标 玩它. 而框架 
提供的是用以 构途游 戏的*础。 

所以框架垃一组为游戏设计者准备的3：具？ 

不，不只如此。我是说，在上一豇把我 卡住的 
那一项功能是框架为个别游戏处理的某件事。 
因此框架不只是游戏设 H •若的 i:A。 

有意思，那么框*是游戏的一部分 （眼 睛闪过星状 
光芒） 吗？ 

嗯，我想是的。但它像是比较低级的亊， 

像是为游戏提供一些基本服务.游戏有点 
像是位于框架之上。 

所以游戏实际上使用框架？ 

是的，正确。 

所以游戏实 R 上使用你正在构建的系统？ 

对，那就是我所说的。喔，等等（心 惊） ，那 

么…… 

……假如游戏使用系统.那它是什么？ （雄出奸笑） 

畚与者！游戏足参与者1 


► *ii»- 在付论问*时.苏輅拉底刁惯采用问答法 （就 是弗种 •你说 说看.你倒是说说看啊"的讨 
厌 a ■格） . 通过提问 . 針对对方®答前后不一致的地方遶行提问，从击揭示对方的&相矛 
* 之* I. 如此展*推进，直到*后取得双方认 T 的《论_ 





行为者不必然是人 


参乌者也是人 
(好吒，不必然） 

结*垃除了游戏设计#之外，游戏本身也是你所构 
达的抿架的畚 U 若. ft 我们怎么为用例 ffl 增加一 



这些新用例处理了那个我们 
无法为它找到归属的功能吗？ 
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解决大问题 


用例思……完成 
涵蠡的功能……完成 

新的畚与#定位珩，我们终于完成用例 ray 功能并 
e 完成 k 对. 



^尖你的铝 I 




最后一个功能还是有点古怪…一 

最后••个功能的第二个部分 （ X - F 移动的 部分） 适合“移动战斗单位”用^ 
m 是 ia 录轮到 I 隹操作的部分呢？我们的用例田似乎还缺少什么东西.你的任务 
是想 出下面这两个 件事： 


• iftii “此柅架 ill 踪轮到淮"的畚 1 


2. 你能增加什么用例來支抟这部分的功能？ 









你的铝 f 
解芩 


最后一 个功能还是有点古怪 



最后一个功能的第二个部分（关于移动的 部分） 适合••移动战斗黾位"用例…… 
m & id 录轮到 ® 操作的部分呢？我们的用例 H 1 似乎还缺少什么东西。你的任务蛙 
想出下面这两个 件事： 


I .谁是“此框架追踪轮到谁”的参与者？ 

游戏 g a 参乌者 … …它正使用此格轚处 戌轮到谁樣作二 


2 . 你能增加什么用例来支持这部分的功能？ 

我(门 ( Take Turn ) 准旮一个两例, 用子 
»a - fear 的蠆本 相兵工 ft . 拜 aa 窖户典戏处否 

ma^tav. 







解决大问题 

那么我们到底 B 经傲？什么？ 

你 Ll 经打 l*Gary 的游戏系统抿架所擗支抟的功能列 
衣.该列衣 ft 诉你耑要构边的所夼 1;® 的系统片段. 

这很》你在第 2«E WTodd *l；Gi na 的狗 f I所达的宙求列 
衣，除 f 它足把热点放在整体轮廊 （big picture) 上. 

使用功能或需求列表来捕捉系统需要 
做的“大事”。 


一旦你让功能或盂求对应完成，便需要为系统如 H 组 
合起来取得基本的想法。就此阶段而言，用例往往太 
过细节化. 因 此用例图能帑你从 10.000 英尺 的商度 # 
右•系统的样子……冇点像应用程序的蓝图。 

绘制用例图来显示你的系统是什么， 
无需深入不必要的细节。 + 






frary 的游戏系统相架 
功能列表 

1.杜相楽支持不商*型的 蚶形。 
2. it 梅架支特不罔时代， 色玄 虏构 
的时代. 如科幻 的成幻想的。 

3. 此相荣相掩游戏的不闻，支紹多 
种类型 的部队乌战斗 簟位。 

«相荣支封用子額外的战役成战 
斗 ft 条的外娃«块。 

5 rt 相* a 供由方格 ® 成的供盘， 
毎一令方栳都》«蚶形类型。 

6. 杜相*绝踪轮 s ，〗 谁操作。 

Z * 相*协 础的 移动。 


... 305 





小组会谈 






Frank： 我不懂你的意思，我想我们一直在谈程序代码。 
Jim： 你为什么会这么想？我是说，“此框架支持不同类型的 
地形-会变成哪•行程序代码？ 

Frank： 你垃说我们找到的那些功能吧？嗯，那不只是 …行程 
序代码，事实 h 是一大段 (bigchunk) 程序 代码. 对吗？ 

Jim： 当然， m 我们什么时候开始谈耑耍编苟哪些*以及放入 
那些类的包？ 

Frank： 很明地，我们一直朝着这个方向在做。但客户真的 
不知道那些东西（类. 包等） 的大部分的意思是什么……假如 
开始谈类与变 a. 我们将无法确认我们正在构途正确的琪物。 


領域穸祈 it 你松 


Jim： 类图呢？我们能用它来显示即将要编写的程序代码，不 
是吗？ 


崔你的珙计，并 
夂： S； 妒著户所用的 


Frank: 嗯，是的，但你认为客户对那个就比较了解吗？事实 
上，这是领域分析 （domain analysis) 发挥的地方，我们以客户 
7•解的用语跟客户讨论他们的系统。对 Gary 而占，那是指谈论 
战斗承位.地形与方格，而不是类.对象与方法， 


诗 t 。 




傲一点领域分析吒 


lb 我们以-种客户 （Gary) 能戽正 Pi 解的//式把;0游戏系统 
所想到的•切姐合起来，这个流程称为领域分析 (domain 
analysis) ,意 ® 适以客户理解的术语描述问题， 



-聲督瓣少 


铂该分柝。 M . 组泛•沒 表矛掮该徇关<|总 的 
笼枝，權搞的4现有类统鸟 萁孖盔 历《的硏究. 賴 
专家捆從 f _) 的知识. 涑存的 理 论以 总领域 S 新兴的 
1 技术。 


















解决大问题 


化整为零，个个击破 

有了客户的认同 以及… 组很棒的蓝 ffl, 你已经准& 

好开始把大 N 埋分解成不同的功能 片段。 接《，你 
便可运用先前所学处理这些功能中的毎 …个， •次 

一个. 时代 （Time Period) 




分解 大问路 


大芦斛 

坫将我们的大问题 （Gary 的游戏 框架） 分解成许多较小功能片段的时候你已 
经打过我们怎样将游戏与其诸项功能分解成几组*本的功能，因此你已经准备就 
嫌了. 

T 面是本章中我们一 i 用来 显示 Gary 的系统耑®做什么的功能4图形，你必须看 
看这些东西. 粮理出 你想要使用什么模块 （module) 来处理所有这些功能，以及 
要怎样分开这些功能与需求。确认你的模块涵盖 T 此游戏框架需要做的毎一件亊！ 
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我伯的大穸斛 




^° ntr0ller ^ 

« (if 我 fOit 3* 个托容轮流 桷作的 和关畢 


这个习题没有唯一正确的解答！ 


在这 冒钱们 处 a * 个蚊车轮浼捵行的和气 
^ t 麯篸本的诂让为攻* 呍进 
Irt - ii 个《 «* <5卢 m + ♦ w 
«瀘的用子 渙我的 " fi .3»^" 


假如你的答案没行跟我们的完全-样， 
那并没有关系，有 忤多 方式可以设计 
系统，这只坫我们选择的 K •中•种。 你所要 扒心的坫 
用你的设 II •涵盎所冇的功能与用例以及你的设 If •坫合 
ffl 的……你不会想嬰校块 1 U 只有•个类 或者打 •两百 
个类， 







解决大问题 



领域分析帮你避免构建 不属于你的责 
任范围内的系统部分。 



mu- 《s 入沒4糾 携 
的球老的技- 子 •. 
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i®3 _ 














解决大问题 


何 谓设计 模式？ 

如何使用？ 

我们令 邯使 hi 过现成的程; r •库与框架。我们使用它们.根据它们的 api 编笱一些程序代码，把它们编 
if 成我们的 程序， 从其他人 Li 经编 1 ■； 的许多程; T 代码获取利益.想想 Java 的 API 以及它们给 f 你的功 
能： N 络. GUI. IO 等. 程序库与框架对开发換 S (development model) 爲有长远的效总，我们能桃 
选组件 （componem) 并将它们适当地挂入 （plugin) »但是它们并未帮助我们结构化我们自己的应 
用程序，使之£容舁理解. 电好维 护以及更具灵活性.那躭是设计模式苕力之处。 

设计模式不是直接进人你的程序代码，而是先进入你的大《。设计模式就是为特定类型的问 S 设计 
解法的方式。一旦你已经将设计模式的好知识栽入你的大 B 中，就可以开始将它们应用到你的新设 
计中，并且在发现们程序代码的品质降低为没有灵活性的一团面糊之前重新修正它们。 
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<* 入浅*设 ' 
式》， 塒设计 «式«*是什么#还 
不知 a. aa*.^«? 


继续往前读吧！设计模式 
是设计的最后步骤之一。 

假如你对设 U •換式不熟，那也没什么 
关系，设 il •模式帮你处理设计的一 

吵 Jft 后步脒-旦你使用像封装 

(encapsulation) ,委托 （delegation) 这 
样的00原則 ill 你的软件变灵活，选择适 
当的设计模式会为你的软件洱增添额外的 
灵活性并且节省你宝贵的时间。 

然而假如你对设计模式不熟，也没什么大 
不了，你还是能够看完这本书，掌握到真 
正坚实稳固的设计 精®。 然后，我们会建 
议你拿起一本《深人浅出设计模式》，看 
看其他人如何处理一些典型的设计问埋并 
且好好向他们学习。 



解决大问题 


感党布点迷惘？ 

我们已经在本 ft 做 r 很多这些唭情中的某 咋其至 
好像不大相千…… 


♦ 收集功能 
♦ 领域分析 

♦ 将 Gary 的系 统分解 成模块 
♦ 发觉 Gary 的系统使用 MVC 设计模式 

但是这些事情中哪一个真正有助于我 
们解决_^句题？ 

记住，这--切的要点在于理解如何处理真正的大型应 
用程序，像 Gary 的游戏系统抿架，所涉及的超过广* 
本的设计与编程。 

不过这里有个大 秘密： 你已经完成处 
理 Gary 的大问题要做的每=石事。 




00 A 补的威力 
(认及一些小常识） 



我 ! HiifMAtCj 个柏达铒 
蜗 . viWisf 
孩 cl# 始 . *94 个 < 

问雄 ,. 、 


_ ® 知 ** 们在呤 4 ㈠ 么 
我们&) 4用例 ® 來 *? 我 (H 5 
«f 休轮廊 



o 聆听客户。 


o 为我们构建的系统画出蓝图。 



注用# 蛾分 W . 我们碡 
认我们 If 沾的 

% 狭《竹 i 。 


o 确认我们理解系统。 





解决大问题 



《深入湟出设讦« 

式》 找出 fc 何 fiffi MVCifiit « 式。 A 运用设计模式帮我们解决较小的 

0 问题。 



恭# f 恭舂 

你 E 经拕大问越转换成 
一稃你 e ■经知遂如何解 
决的较小问瓸。 



OOA&D 工具箱 




00 A 邡 i 爯箱 


你己经承担了大问 H. 而且还是虼立不动摇！回顾一些你已经学到的 
关于处理 大问題 的相关事项.接着准备回到 OOA&D 填字游戏。 



垂步分 解 W 、 冊 



聆蚵客户.找出他们1伢 构速竹 


戒 期邦枵 

设4农耔6 么。 

在 本# 我们 AtH 5- 

5|认你的 

值 用溥扣 3用客户理铒的该言组合功棍列表。 



来祕 （ 场认你的功翁 & 客户真正@5的 


法用你栌 

如蓽 i 4 砷 i 系 甚。 


你的 搴。 

at * 

00 康則 

饬 的用制 

统的 ®。 


•潘的 f 求 
进係的 JS 


p ) Hatm . 系不*的实现: 

作鈹得 将说分 桷式注用利系统中较 .) ■的 

在用《埤的*_个*.口 •有一 

你的 IM 


个 JI 由 aii , 


) 雎 屬收件 （钟 才。 

* 括砝努；注用暮本的 0 OA & D 琢 B |)；6 备一个 

类蕞兵子行泠岛功昶的。 

k 要点 

较0•的郝分设0«序。 



看待大问題的方式是将它视为一组较小问题的 
集合， 

就像在较小的项目中那样，从收集功能与需求 
开始进行大项目》 

功能通常 a 系统做的“大”事.而且能够与 
••黹求- … 词互换使用。 

共同性与变化性给予你在新系统与已知事物之 
N 相5比较的 观点， 


■ 用例是面向细节的，用例图则是比较聚焦 在整 
体轮廊上。 

■ 你的用例图应该顾及系统的所有功能。 

■ 领域分析以客户押.解的语言表示系统. 

■ 参与者是与系统交互伹不属于系统的•部分的 
任 M 寧物。 




解决大问题 


OCM & D 填字游轶 

动动左脑的时间到了。下面的字谜有许多空 
白方格，右边是一些线索。你知道该做什 
么，那就动手吧！ 



横排提示 

2. This helps you spedk to the customer in 
their language (2 words) 

3, You can use your feature list to moke sure 
your use cose diogram is this. 

5. Use cases don't aJways help you see this (2 



7. These aren't always people. 

8. A feature is a_description of 

something a system needs to do (2 words) 
10. Art Vandelay's m rtal" lost name 

12. A use case diogram octs os this for your 

14. You can figure out these based on your 
features. 

16, This is the measure of how things are 


竖排提示 

1. An oval in a use ccse diagram represents one 
of these. 

2. We applied ones of these to your Gary's 
framework. 

4. The measure of how things are different. 

6, You should solve o big problem by doing this 

to it P words) 

9. You con figure oat a system's features by 

_to the customer. 

11. you solve big problems the_you 

solve small problems (2 words). 

13. Defer these as long as possible. 

15. He wasn't the customer. 









习题解答 
























你必须从某处开始，但最好挑个对的地方！ 你知道如何把你的应 
用程序分解成 仵多小 问題，但这代表你有许多小问题。在本章里，我们将 
帮助你想出从哪毕.苕手，并 a 确保你不会把时 N 浪费在错误的事情 h。 现 
在是让我们把工作空间里四处乱放的所有小片段整理整理，并且找出如何 
将它们转换成有组织.设I十良 好的应 用程 if ■的时候 r。 整琪 r 来，你会学 
习到里耍的58构三问 (3Qs of architecture) 以及风险这个 ® 要的议题， 


进入斯章节 
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从哪里开始？ 


感觉有点头§码？ 


这枰，你已经存了许多知逍如何处理的功能性小片段，你也打 


了用例 ftl . 功能列衣以及 I 午多其他要想的水。 


ftarv 的淇戏系法相》 
功陡列¥ 


1.*栢*支妗不@*«的械®。 

特不尚对代. 包玄® 构的 
»»«. 4»»« 的 «幻»的。 

3. ***«*« 戏的不 》• 支特多种 
ss «»^ sa 斗*® • 
♦.*«*£»« 子额 外的故 «*故斗 
场 肇的外 

5. tt ***«* 方糖®成 wwft . 45 
-个* 格 》翼《珀肜*®。 

6. ft 糫 *»»»«** 作。 

Z * t «* 协《*«的» 珀。 


我们有功能列表 + 



要编码的单独模块' 
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架构 



_ M-y- C 沒 

， — fKa 



••甚至有设计模式可运用。 



客户的远景 


你认为应试先做什么冇那么*要吗？如采你认为是的 
话，为什么？你会先做什么？ 
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我们 f 要桨构 

只想出大 N 理的黾独片段事实上是+够的，你还需要知进这呰 
片段如何 m 织在•起以及哪呰 " j ■能比较® 要。 这样的话.你会 
知道应该先做什么， 


我们魚… 
穿构坏*们 a 外歸螫 *■ 


■t，. ， 

构雀 r < t 楚 


Architecture is your ( 译注 ■) 

design structure, 

and highlights the 

most important ' 

parts of your app, and the 

relationships 


琛在. 这 逐 我 
们 t * 的彦 
*•••_•• 我 m 
-样找出付么& 
4 < *w. VJ. 
噯我幻《光构 
瓊在用<«4的 
«个#分 ？ 


between those parts, 


* fi-.it «»« 4 
乒含这4鹑 W 
t * 的 …… 饬们必场 食 
部的穿构. 




LM：\ 


穿构，穿构甚系统的纽 iP •结构. fe 含分鹆孖来的各个 
部件，它们的连 ii 性，4 5机剌以 A 仿•在系 统议外 
值用的推 导涿 則务: 夫菜： 







架构处理大湛税 


架构 
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我们还是在构建伟大软件 


不管项目的大小，你都以相同方式编写 

伟大软件，还是可以运用我们在第1章 am * 丨 ㈣ -费唼： 这三个 

所谈的三个步骤。 用子构的⑽ - A - 政 



真正大的应用程序 
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架构 


从功能孖始 

第一个步骤总&确认应用程序做它该做的亊，在小項自中，我们使 
用需求列表 (requirement list) 写下功能性 (functionality) 1在大 
项自中，我们使用功能列表 (featurelist) 螫理出那些事: 




但 I 哪一个是最 重要的 ？ 

即使知 进从聚热于功能性开始，我们还是要®理出 
iti® 逛的 功能性片段足什么，这呰逛我 ff I想要先* 
热的功能性片段. 
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从功能性开始 


尖你的铝 I 

你认为什么是最重要的功能？ 

即使我们的功能列表里只有7项功能，在这7项功能屮也有许多工作要 
做。你的任务是找出你认为最®要的功能，然后是你要以什么顺汴做这 
些亊. 


frary 的游戏系 统框轚 1 
功能列表 

2.此襁楽£»不罔对代. 包宫虚构的 
»♦«. 如科幻的或》濮的。 
5.此《*供*««的不@.支»多种 
类轚的期 队乌战 斗攀位 • 

4. 杜權*支«»子《 外的 《«*« 斗 
« i 的外洩 祺蛾。 

5. 此《*熳供*方松《成的供纛•籌 
-1 •方格》»««»»«。 

6. 此《*4踪轮則》 嫌作- 
ZA 權*协谲* 雄的»功。 


- fEiu/rt 以《存 瘃敵削 


^物4 奸 


饫屢老 礙的 4 咩 


2 .. 


3、 
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架构 


应芹桟/?中其 )E 
重要的亊憒是 
弈构上重 要的事 
( architectural] y 
significant ), 

侪 应 该$ 杷诔点置 
子丼上。 



你必须从某个地方下手！ 


要想出这两个模块如何交互，至少要对这 
两个模块有些适当的基本认识。 

所以架构不只是应用程序中部件之间的关 
系.也要整理出哪些部件最为重要，因此 
你司•以从构建这些部件开始。 
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什么是架构上重要的？ 


架构三问 


-1 你 Will 想出某件事坫否对架构很®要时，可以问问下《的3 
个问 8h 




1. 它是系统 本届 （ essence ), 的 
-鄯分码? hm 


该功能真的是系统实质意义的核心 （core) 


吗？像这样想 想看： 你能想象系统没有这个功能吗？假 
如不能，那这个功能可能是系统本质的一 部分。 


"'tjumm 么意 s? 


琅 t ) 丰 部的 !I 汉： 


H -到焱" *» 代揉来 
釋3 个字。 


假如你不确 定祐项 功能的叙述究迮垃什么息 A!i. 把汴意 
力放在该功 能上吋 能就很道要。甸当你不确定某件亊怙 
是什么，它就■■了能会花费你很 多时间 或者对系统的其他 
部分造成很多 H 题。要在项目早期把时间用 ft 这样的功 
能上，而不是晚期。 


多.我“到陔”该如何§? 

男一个要在早期就把注意力集中到的地方.是 
似乎真的很难实现的地方，或者对你来说是全 
新的编程任务。假如你不知道如何处理 某特定 
问 a, 婊好花点时间去正视该项功能，这样它就不会在一路上产生 




进多麻烦， 
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右达 龙我们 在上—章整琪 
出弗的功炜到恭。侪的 
^ 任旁是伊涑猓构佣 

? 的角色，強过筘审 
铁到的“猓构三洵 • ， 
找出什么是在猓拎上重要 
的. 


什么是很重要的？ 


检 tiiftt) 脊嚤* 饬<1弟330 S 
ftSW 普* <5多纽迨 _■ 


架构 


fary 的游戏系銥相襄_ 

功能列老 

1 . rt 相* 支材不 0 #型的 rt » a 

2 . «相*支辩不 0 时代.色玄虚捭的 
时代， 如科 幻的成 幻®的。 

浃赶相 架相薄游戏的不罔.支持多种 I 
类型的部趴鸟 a 斗*位。 

冬《相楽支持用子额外 的战役珀战斗 
场彔的》接«块。 

Sft «* 嫌供由方格姐珐 的供盘 .苺 
-个方格郝災布《形#型。 

«•««* 埴踪轮《谁操作。 
z « 相*协础的移动。 


为什么？ 



写下 it 用 <5 (j 
1的 —穿构三 
闷-闲》 (有 f 


4 的译， gg - 


个 W _£) 。 
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t 轚软出弗 I 
^ 刊泰。侪的任多 j 
( 抟饰的角色， a 过前 

.9 *>. - »!■ *fc »r It» " 4J! 


右达龙我们在上— 
章聱琪出弟的功侔 
. 侪的任旁*轵求弈 
a 过前孩铁到 
的•笫构三佝”，找出什么 
龙在深拎上 霣要的 u 



夺 ary 的游戏系统相架 

~― 

1•赶相*支特不同类型的蚶形。 

2•赴框架支辩不同时代，色玄虚构的 
时代， 如科幻的珀幻想的。 

3. 赶桓架 相痗黹 戏的不目.支持多种 
类型的部队乌战斗簟位。 

4. 此框架支抬用子额外的战役琏战斗 
*1 的外挂 找坫。 

5赶相*拽供由方格组成的梢盘，毎 
一个方格邾爯布《形 类型。 

6 •赶相 架堆踪轮到谁埭作。 

Z 赶相架协调5雄的移动。 


我们认巧部 K ■对豸戏 
4 至兵重蘑的…… * 
^ p^-at ••薄相 
定-的4立金义* 付 
£ ® 时有》个闷迓 

出现 «Cjf . 


iA «4 <5 ■«■«**• 

我们接 

找 d 它的金义以 a 
峩们«*漱<+么。 





% 


|o). 对于你所谓的系统•■本 
质”. 我觉得有一点困惑.能再说 
清楚一点吗？ 

^ . 系仗••本 項- 是指在最 
基衣的*次上系统是汁么，换句谙 
说，靓如你去除所有的修坤.市场 
部去进来的杂音以及所有很酷很炫 
的想法，此系统会是什么？那就是 
系统的本质. 

当你*看一項功詭时.问问 自己： 
-«l 如这个功能没被实现，此系统 
还会是它应该是的东西吗7 " 如果 
答**否定的，你便找到一个••本 
廣功艇* (essence feature). 在 
Gary 的系统中.我们判断如果没有 
棋4与一*战斗单位（请参考本 W 
底部的■•动动鷗 •） ，游戏就算不 
上是真正的游戏， 

(p). 如果你不知道某件事的 
意思.这是不是你有了坏*求的征 

兆？ 

^ . 不，但它还是你可能需 
要**额外需求的征*,在早期阶 


段，你可 ft 在取得系 仗的基 本认知 
上漏掉 了莱*細节》是在此阶段. 
是该把那®细节朴上了.这* "架 
构三问”的»二问所关系到的事。 

|o). 假如我正在开发新 系统. 
我可能不知道如何做功能列表上的 
任何事.那么"架构 三问- 的第三 
问不就总是成立了吗？ 

^ . 不，根本不是.例如，即 
使你还没編写 C 序代妈来判定玩家 
是否 要输 入字母 “q •或 -X •.但 
你知道如何編写基本的 if/*la* 语 
句，来获取此家的鍵4 鍮入 也很容 
易，因此.像取得 《■¥ 鍵4榆入这 
样的功能就不是你不知道该如何做 
的事.即使你没有特别为昴样的任 
务編写过<1序代磷.它只不过是一 
些新的细节而己，真的. 

但是，飫如休 必須編 写多线<1的聊 
天服务而你对线 a 与网络通信 
编《不甚了解，那就是莱件你不知 
道该如何做的事.坏些•是你要小心 
的事： 你不确定要如何处理的困堆 
任务。 


( o ) :那一 切最后不就都变成是 
自己判断 (judgementcall) 了 B?? 

^ . 在许多情况下.是的 •（B 
只要你选择开始进行这*对系«•似 
乎相当重要的事时.你便有了一个 
好的开始。 

你不想倣 的是： 看 見某件 好诹很》 

悉的事，或许己经在另一个項0中 
解决过的相同问*,并 A 从郢里开 
始。从系统的核心片段以及看起来 
可能特别难的事情开始，你将会少 
上成功之路. 

系铒的本质; fe 
祚在最 基本的 

什么„ 


I 你认为这些系统的毎一个本质蛙什么？ 


♦ 气象监测站？ 

♦家用自动遥控器？ 

♦节奏控制，混音 D〗 设备？ 
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tel 还布 一维 事要做 






架构 


争论 



Joe ： 拜托.很 4 f 文哦。即使垃系统的本 W . 你也必须想出游戏特定的游戏单位是什么。假如它比我 
们想的还难的话， - f 能得花上几个礼拜的时间编写！ 

Frank ： 也许吧……但我们知道协调移动足很堆的，因为我们还没有线索提出该怎么做！当你知道移 
动的 H 題会很难处理时，你怎么可能做任何其他事？ 

Joe ： 佤游戏特定的战斗单位也可能很难！我们就是+知道嘛， ifti 那就是我的 重点- 我们必須想出我 
们一无所知的系统部分，否则它会是一个真正的大麻煩！ 

Jim ： 你们两位继续在这里斗嘴，去写你们的移动引擎及战斗单位，我走先，我要先写棋盘.因 
为 …… 嗯……我可以感觉到， Gary 会想要先看他的棋盘游戏系统的棋盘，我不打算把拱盘留到后面， 
我要先处理它。 


Frank : 你们 两个® 瓜，你们是在拖延困难的工作，我要马上处理让我不描不着头绪的事。 

那你认为谁是对的？你 同葱： 

□ Jiw (构違棋盘） DJoe (构違游戏特定的故斗单忮） 

. O Frank (构違桴动引擎） 


*jiS 4^(*) 
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问 B 在子风险 



始.只要你把焦点放在构建你应该构建的东 


西上。 
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刻尖你的铝笔 


找出你自己的项目的风险 


想想你白天工作时正在进行的项目，写下你开发项 H 时所做 
的第一 件事： 


现在，想想我们在第323页所谈的架构.:问 . 把它们应用到你 
的项 B 中，写下几个你认为在架构 I :®要的 功能： 


假如仔细苻看那些功能，你岈能会看到它们全都 1 g - 许多风险 
相连接 • 它们可能带给你许多问題，或者延迟项目的完成。 
写下你认为哪个功能应该先进行以及原因是什么 # 它产生了 
什么风险？什么风险可能因为你先处理它而减少？ 






弈构拼留 

对于 G«x:y 的游戏系统来说，我们从棋盘模块幵始，你的仟务 坫编' Bo«d 
界®,供游戏设计者使用与扩展_来构 边他们 ft 己的游戏。 


问题 


你擗要一个 Board 基本奥游戏设计者能用它来创 it 他们自己 
的游戏。棋盘的高度与宽度由游戏设计者针对他们的游戏提供。此 


的 乘以谇 




外，棋盘 (board) 能返回给定位 H 的方格 （tile) ,增加战斗单位 
(unit) 到方格上，并且返回给 X-Y 坐标的所有战斗单位。 

任务： 

o 创建名为 Board.java 的新类。 

Q 为 Board 增加构造函》,接受商度与宽度并且以此卨度与宽度创违新 


棋盘。该构造函数也必须以矩形的方格填满棋盘，毎个 X-Y 坐标上一 
个. 

o 编写返间给定位《 t. 的方格的方法.绐定该方格的 X-Y 坐标， 
o 编 y 方汰来将战斗单位增加到位 T- X-Y 屯标的方格。 

O 编写方法来将方格上的所有战斗单位返四，给定方格的 X-Y 坐标. 
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I 钃癱嫌 一鷉鶬 


本周 专访： 

场景 （ scenario ) 有助于减少风险 


架构 


Head First ： 你好，场 S 先生，欢迎来到我们节 H , 感谢你今天抽空与我们 聃天， 

场最： 真的很髙兴能来到这 m , 特别娃这一拿并非关于用例。 

Head nrst : 是啊，说真的，当我被通知 i 方问你时也是相当惊 W 。 我们在此本应该把焦点放 
在架构上，并 a 做会减少风险的功能。 

场景： 绝对是的！嗯……那听起來像是处理大问囲的好方法。 

Head First ： 是啊，嗯•…"呢;……那你为什么在这里？ 

场景 ：喔， 不好意思，我以为你知道，我在这里也是为了帮忙戚少风险。 

Head First ： 但是我以为你只是通过用例的一条特定路径。我们甚至还没写用例呢！ 

场景： 那没问题，我还是真的会有帮助。我的意思是 …… 呃 …… 说真的，许多开发#并未真 
正花时间坐下来好好写出用例.真是可惜，在第6$,我们其至花了4页的篇幅来劝人们运用用 
例 ffl 。 绘制用例图可是比编写用例容 S 多了， 

Head First ： " fi , 那倒是典的。编写用例冇许多阻力，然而它们真的有帮助，我想是它们拯 
救 f Todd 与 Gina 的狗门。 

场 景：嗯 . 我冏意！但在有些情况卜‘开发荇就坫没有时 N , 或荇用例对所耑要的东两而宫太 
过正式. 我离的 町以给你 I 午多用例的 4 f 处， rfii 无霜所有的书面工作》 

Head First : 嗯，听起来很吸引人，告诉我怎么做。 

场景 ：好. 以你 一 fi 在编写的棋盘为例.假设你要减少 Gary 看到它时想到某些 S 要的事，而 
你却忘了加上去的风险…… 

Head First ： 啊，是的，忘记重要需求总是一个大风险！ 

场景 ：嗯， 你可以从棋盘如何被使用想出简单的场景——那就是我着力的地方，然后确认棋 
盘和场铁中的毎一件亊一起运作。 

Head First ： 但是没有用例……在我们编造的场景中要挑选什么步骤？ 

场景： 不必那么正式，你可以说■•游戏设计者创逮新棋盘，8格宽，10格高 •. 以及“玩家 
1歼灭了玩家2在(4,5> 位 置上的 部队，所以棋 a 将玩家2的部队从那个方格移除 " 。 

Head First ： m . 所以只要有-些拱盘如 H 被使用的叙述即4, 

场景： 很 4 f , 你弃 trn 接荇，你运行紐一条叙述，确认你的机盘处理/•耶咋状况， M 然+ 
如坩例那样彻底， m 我戽的能够 w 你确认没有忘 ki 任何大耑求。 


Head First ： 太棒了！广告时间到了，我们4上冋来继续谈话， 
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找出 


为你刚明编码的 Board 界面编写场最。 

减少 W 险是本章的土轴，你已经根据我们给的潘求编■^丫 Board 界面，但坫想想我 K 味的風 K 

们垃否忘了什么*也是你的1：作一在 Gary # 见你的 结采并 发现错误之前„ * - 

你的工作是从本页底部拿到场景的片段， W 把它们按照合理的颟序放到布告栏上， 

此场 S 应该运行完游戏的现实部分。当你完成时，看看你 是否在 Board 界面上遗 
漏 r 什么，如果有的话，将遗漏的功能添加进你的程序代码 • 你可能不需要用到 
所有的场景片段。祝你好运！ 







架构 



真锖隽数 一鷄倒 

本周专访： 

场景 （ scenario ) 有助于减少风险（续） 


Head First ： 坎迎 N 到这 3 i 。 场 S 先生，我 ( H 接到 r 凡通乜话，你介麻问答 • F 听众朋 友们的 H 明 
吗？ 

场景： 没 NS . 很荣幸有这个机会。 

Head First ： 太好了，首先是一个很多人在问的问埋，来自爱达荷州的梅耐心先 生问： “你是说我不 
再需要编写用例，是吗？可以只用场 a ? ” 

场景： 谢谢你的问题，梅耐心先生，事实上，我经常被问到这个问题。我坚信只要有可能，你应该还 
是要编写用例。我对快速的问题 (quick problem) 有帮助，并且能找到大部分的一般需求，但是要记 
住，我只是通过用例的“一条”路径。假如有许多替换路径 (alternate path) 存在，若只用场 S , 你可 
能会错过一些 重要的 需求。 

Head First ： 没错，事实上，我们之前曾经遨请快乐路径 (Happy Path) 先 生与替 换路径 （Altemaw 
Path) 先生来上我们的节目， 

场景 ：嗯. 它们实际上就是我的 If •实版。我们试糖+去谈太多我们的京族关系，我们全 W 想辟 fid 闯 
出一点名堂，不过我们确实邯地 Scenario 家族的 •》. 你们真的擗耍我们所有人的 W 助，才能鴒定 it 系 
统完全正确.假如你才开始，用例似乎有点太早熟，使用我才垃起步的好方法。 

Head FNrst : 好，另一个问题，來自内布拉斯加州的神京直先生问：“你说 你会桢 我减少风险，我 H 
厌风险，我痛恨风险，你可以快点告诉我怎样避免风险吗？” 

场景： 又是一个好卩题。神京直先生，您放轻松点，我马上回答您的问题。记住，当你在整理畨求 
时，无论你使用的是用例.用例图还是场景，你就是在设法确认你在构 建容户 想要的东西。没 有好需 
求，构建错误之事的风险会让客户很失望，很不高兴。 

Head First ： 那么，你是在需求阶段 （requirement phase ) 减少 风险？ 

场景： 大多数情况下，是的。那是当你在写用例.组合需求列表井且使用许多场景，在用例上标示出 
所有通过的路径时。 


Head First ： 但是，你对大型项目的架构也有帮助，垃吧？那垃我们邀请你来参加节目的原因喝？ 
场条： iK 确。打时候，你没有完整的需求列表以及用例，但你还是需要完成一些基本工作.看看 
系统如何运作，那坫我们在此-崑在做 的事： 运用场 S 来获得換块的某础成若程序代码的片段. W 此 
你能获得适当的应用程序构述块 (building blocks). 


Head First ： 所以你典的垃个方便的好是不是啊？ 

场景： 希爷如此。我帮助收粜需求，侬助确认你的用例完《,而且在架构中帑你减少风险， 减少 混乩 
*5 困惑.澄清特定的換块或程序代码片段要做什么《 
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减少风险 


场景大搿盘解荅 

为你明刚編码的 Board 界面编写场最。 

下面是我们想到的场铁，你的答案可能有点不同，但是你至少要 It 游戏设计者创 
达棋盘.让玩家 I 与玩家2之间的发生战斗以及让战斗单位被增加或移除。 









、常〜 題 

M. 


I®) : 第 340 页上的••架构拼 ffl ” 中的那些需 

求从何而来？ 

^ : 来自 Gary, 外加一*常识。氙如你在 
想 Gary 对游戏系统枢架有什么要求，就再 to 回第 
6 幸，读一读••客户的对诂”（第 288 頁〉， 你可* 
就会自己想到这痊需求。我们的确增加了一些规 
格. 如《«把战斗单位加到种定的方格上，但那 
真的只是把问题更彻底地想清 楚一* 而已. 

I®): 但我们为什么不写下用例来螯理出需 

求？ 

^ : 是 可以. 但记住，我们不是在试着完 
成 Board 模块，而是只要获得合适的基本片投. 
坏是 我们为完成 Gary 的系 统 的这个片段所需要的 
一切.亨实上.》如我们太过深入细节. 就吁範 
会实际增加項目的风險.因为处理细节并不是此 
Ifr 段玄要的事。 


1®) : 你是说用例会壜加风险？不会吧！ 

^ : 不，不 是的。 当运用的时机正磯时. 
用 例不会 增加风 tt。 现在我们已经想出一*关鍵 
功能. 级如没有把它们整理清楚. T 是会让我们 
头 痛的. 但这并不表示我们需要让 Board 界由尽 
善尽美 • 我们只是要对它如何运作取得了解，这 
样级如有任何潜在的问題.我们就能 •« 权住并且 
&成 避开此问*.所以此时，你要編写用节 
的意田是有点过头了， 

然而.一旦我们单拟出关鍵功能并处理好 主要珧 
险. 我们将田到每个橫块来真正开始加入节。 
屆时. 用例将会非常有帮助。 

r ^ i :那么.这就是我们运用场最的原因 
吗？为避免深入太多不必娶的细节？ 

^:正确.场景给我们许多用例的好处， 
又不强制我们深入谇多现在不需要了解的蛐节. 


猓构拼囪 




Board .java 遗漏了什么？ 


仔细看看前-的用例，我们在第340页所使用的需求涵盖 
了完成的场最里的毎一件亊了吗？假如你认为有什么遗漏了， 
将它写在下面的空格中，然后为 Board . java 增加程序代码以 
处理遗漏的功能性. 



猓构拼闺斛著 


对于 Gary 的游戏来说，我们从 Board 播块幵始.下面蛙我们为 处琍棋盘的基本工作 
所写下的界面》将你的答案跟我们的比较一下吧. 


package headfirst.gsf.board; 

import java.util.ArrayList; 
import java .util. Iterator; 
import java.util.List; 

import headfirst.gsf.unit .Unit;. 

public class Board { 


存華 6 # 所#定的携 


. 这4我们 Si* 钻*的 
灸, ©妗我们**它污皤 
龙威 BoMil。 


private int width, height; 
private List tiles; 


public Board(int width, int height) 
this.width - width; 
this.height - height; 
initializeO; 




£ 



: void initialize 。 { 
iles = new ArrayList(width); 

:or (int i=0; i<width; i++) { 
tiles, add (i, new ArrayList (height)), 
for (int j=0; j<height; j++) { 

((ArrayList)tiles.get(i)).add(j, m 




我(门《供6 I ： 的这螫匆格 
表 5： 成 «»*»«•< 

( tf -; i 2). 以 t 4 岛惠度 
作於 钂 A 。 


奋 《_个4杉点 _ t . 加 卜个仙 
的贫例 • 我们也 jIj 铽 篇戌类 . 

**^-^arno(sit>e.Tu K 


►译注2:对于随机访 问对象 来说，使用 ArrayLisl>I •以 得到校 好的性 
对于涂或拢入对象来说， LinkcdLisl 在这方*就好多 
T. 在本 W 中.棋金上的方格在创建 W4 时便一次定成.因此 
ArrayLisI 是较 合速的选擇。 


0 

Board.java 





架构 


&不# ti 炉 —► 

的1 

expUiMloiy) . 1 

4C4#340S 
L<AM 求 W 一郝 
分。 


public Tile getTile(int x, int y) { 

return (Tile) ((ArrayList)tiles.get(x-1)) .get(y-1); 


public void addUnit(Unit unit, int x, int y) 
Tile tile - getTile(x, y); 





public List getUnits(int x, int y) 
return getTile(x, y).getUnits(); 




. 个我们 i 托沧 Tl1 * 
类的 地方。 因妗方择了 
战斗辇佬.的以孩《»战斗*倍 
农 kx ：4 方路的 


1^1 : 使用数组的数组 (array of arrays ) 是否把你限 
: 制在矩形的棋盘上？ 

^ S 不.不会的，尽管它确实将你 m 制在使用 (x.y) 
i 坐标的棋4上. 例如， 你 T 以在由六边形方格所紐成的 
! 六边形棋4上使用 ( x . y ) 坐标 （舨如 你正确地 teR 坏*六 
；边形方棬的 请）. 钽基本上.数 te 的数纽主要还是速用 
；于 tt 形方蝽的 tt 形棋盘. 


I ®): 这还不是限制吗？为什么不使用围形甚至 i 

Coordinate 类，好让你不受限于 （ x , y > 坐标和矩形棋盘？ 

V : 氙如你想 ♦有最 大的灵活性，那 " T 詭会是个好 i 

主意.然而在此情况下，我们的需求（田头看第340 霣）； 
明 璃指明 ( x , y ) 生标，因此我们选择 一个不 繹 么灵活 <8确： 
实比较 *1 单的解法.记住，在此阶段， 我《1 正试 着戎少 
风 ft , 而不*找一个比我们实》所需还*复杂很多的解； 
法来增加我们的 风抢。 
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■?«!*) 


.•它 的. 


T «* 有一个)|教战斗#仿 
的列表 （ Ci « t ) 。 —. 


这费甚如奶^用 瘃搆枞 
政斗#(他方法。它们 
&p _“. 

以扶 闲它 ( n 。 V 


保特正碥的恁点 ^ 

你不必袒心 Til * 1 -j tin it 最后要做的事情是什么， 
你的热点是 itBoard 和它的关键功能可以运作，而 
不是完成 Til * gonit , 这是我们 IhOnitW 内容这 
么空以及只增加少数几个方法到 Til « 屮的原因。 






— %杷诔点歆在 
—个功熊上，减 
少項 g 的凡胗„ 


少凡 胗的功鲜穸 

心。 


埋 

% 


架构 


1^ : 假如 Tile 类处理战斗单位的增加与移除.而你能够使 
用 gelTile (> 从 Board 取得特定坐标上的方格.为何还*增加那些 
addUnitO 与 removeUnUO 方法到 Board ? 你不能只调用 getTile () •然 
后再用 Tile 来做事吗？ 


^ : 你可以采取这样的方式，让所有与 Unit 相关的操作遢过 
getTile 0返回的 Tila 对象被直接处理。 我们 决定增加 Unit 相关的 
搮作到 Board. 让 Board 成为游成设计者的进入点 （entry point). 
事实上，你将在下一页看到我们 itTile 的方法成为 protected， 
以至于只有与 Til ■处于相同包的类 （像 Board) 才 ft 直接诵用 
addUnit(> 与 removetJnitO 方法。因此，我们实际上已经碟认 
Board 是被用来操作板块与战斗单位（最后还有 地形） 的对象. 


1®) : 我还 ft 认为继续增加一些我们会用到的方法给 Unit 与 
Tile 会很容*,为什么现在不多花点时间在这些类上？ 

^: 此时你不*在设法 ft 整个游 咙系统 ffi * 鴆码.而是 在处理 
一*关鍵功能并且成少項 B 的主 要风險 。现在就芘时间编写 Unit 或 
为 Til * 增 *0 畑节真的不会帮你减少成綸：相反地.只要做足《让 
Board * 运作起来的事•就可以了，因为我们判定 Bo * rd 是系统本肩 
的一部分，而且极如我们没把这个片段处理好，就会有失敗的风 
险. 


一旦处理好你的关健功能并且减少或消除项目的大成险，你就会有 
很多时间处理其他功能，诹 Unit 类。然而在此 8h 段.你正试 着进兔 
花时间在无助亍戒少項目 风汝的 任何事情上. 


rB 9 在线时间- 

你可以到 http://www.headfirstlabs.com 卜•栽 Gary 的框架中这些与 
Board 相关的类， R 要 ；?. 找 "Head First OOA&D” 并且找到 -Gary's 
Game System - Board classes 1 " 即町。 



魆多次序，越少湛秕 

我们的架构与关键功能列表已经 帮我们 取得了适当的 
Board - ft , 并确保我们正为客户捕捉住系统的本质， 

回头看#我们的关键功能列 表吧： 

&ary 的游戏系法相楽 
兵鍵功能 
——系法的枣*。 

2.*««定的 a 斗 * a —系統 《♦«. * 达* «- 
——达 * fl ■么* ». «««*>««? 


我们现在也 B 轻有？结构…… 

«梓的坫，我们已经适当地准缶了一 些基本 的类，而且 
我们可以开始想想•个关铀功能汴让它融入此结构 



ft (H 6 a ** S "i t 本的 
Bo > i ^ % . ©此我 
If 好达个荚《功翁.芍以 
期进 《下-个。 



I) 



捿 T 來淡傲啷个功能？ 


架构 



罄本我们芍以 
闵如 rat 
5. 4 E <1 我们现 
<5的 ♦物 i 科姹构 

澧 



不能谈论部件之间的关系。我们知道 Board 
与 Unit 是相关的，而 •■游 戏特定的战斗单 
位”是关键功能.因此很明 B . 那是下 一步要 
做的亊。 


►烽注3:此 a 译为 "架构是你的设计《构.强调应用 a 序中最 •* 要的部件以及那 
*部件之间的关系 - , 
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去了解你不知道的事 


游戏特定的战斗单忮 
那 I 什么 t 思？ 


再多 J * 解点 “游戏特定的战斗单位”的》简雄方法，就 
是与 Gary 的一 些客户 谈谈，也就足和将使用此框架的游 
戏设计? f . 听听他们有什么要说的： 
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1削 尖你的铝 t 


“游戏特定的战斗单位”是什么意思？ 


既然你已经听到•些要使用 Gary 的游戏系统框架的游戏设计者的 
谈话，就应该对我们的第二个关键功能的内涵有一些好的想法》 


在下面的空白处写下你认为支持“游戏特定的战斗单位” 需耍做 
什么. 


做0完成 （ 

— 你的芩®岛我 

一 彺 f 一灸的答 

— 作 tt 较。 




4 尖你的铝 f 
解答 


‘游戏特定的战斗单位” 


是什么意思？ 


既然你已经听到一些要使用 Gary 的游戏系统框架的游戏设计者的谈 
话，就应该对我们的第二个关键功能的内涵有一些好的想法。在下 
面的空白处写下你认为支持“游戏特定的战斗单位"需要做什么。 


裤荅 


毎个 S 子杜楢荣的《戏 異笮不 a 类茔的 a 斗簟 a , »笮不同的 
屋性 ( attribute ) 乌能力。我们必■涵 疾够相 痗不目 游戏为 战 
斗攀 a 准杳不罔特性 ( properties ) . ns 为并塋特性 准旮多 f 
rn - mikH . ( datatype ) 。 


-螯 f 队和 M 的游戌芍戗 
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珙计 _ 

I 你的任务是想出什么是共同的 《common) —应该是基本的 Unit 类的一部 

分，以及什么是变化的 （varied) ——珐属于游戏特定的 Unit 子类.在下面 
的类 IS 中，写下任何你认为是共同的特性与方法到 Unit 类中，然后增加任何 
你认为是游戏特定的特性与方法到子类中. 





架构 
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再深 入一点 


解法 *1: 全都不罔.『 

乍看之你•能想到类似 F 面这样的解法： 










架构 



有类型 （ type ) 以及一组特性，其中每 
一个都是简单的名/值对 （ name/value 
pair ) 。 
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共通性创造灵活性 


解法 吆： 全鄯相罔 .r 

i « f 仔细想想，你可能想到类似 T 而这样的 解法： 



以的耷咖* 5 : 
8 匆伐的方式似 



甙 8 («至《 个«斗! 
318). 力《. * 度, 
琿记以双 豸* Si4,’+ 辛: 
«佝《他搴食部芍以 
p?opeities 的 Map 中。 







架构 



你认为哪个解法更好? 

钱爭薄冲中 '作 为什么？ 

不*代£: - 
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a 斗荦佬类的 

fef 

a 斗辈佬类的數《 

m ： t#o 

a 斗辈话的类數 1 

3 

4 

( 

5 

6 

1 

(0 

U 

( 

25 

26 

( 

50 

5( 

f 

(00 

^ 10( 

f 



後用 鷂法货 2 . ，- UlI((<|t 
典性。 


僅用《法# 1 . (念运 * 奄_ 
个 Unit 善走.斿 B * 个战斗 
辇 •■个子走。 



_ Unit _ 

type: String 
properties: Map 
selType(String) 
geIType(): String 
selProperty(Slring, Object) 
gelProperty(String): Object 


7 的 

的 Unit *. 我们鈦 皮 
妨《砉蛊* 的 7 均钱 
4# f 2 *S = 


我们识别出共同之处并将它放 
进 Unit 基类。 _i ■果是游戏设计 
者现在只需要注意 d 战斗单 
位类型，而不是 26、ll 或101 
个！ 


% 

I ®): 我能明白这会如何帮助我的设计.但这跟 

减少风险有什么关系？ 


势珙计&長会 
减少凡胲。 


^ : 好设计总是会减少风险。通过思考最好如 
何设计 Dnit 类，我们能在第一次就把它做对……并 A 
是在深入做整个游戏系统拒架，以及 必須对 Onit 做巨 
大 t 化而影响许多其他《序代玛之前. 


我们不 仅想出“游戏特定的战+单位 • 是什幺意 .S, 
而且定义出基本的 Unit 类，现在.像 Board 这样的其 





架构 



我们只聚焦于会 减少风险 的事。 
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、劈心匈題 

% 


I®) : 在做 Board 时.我们确实为 

Board 类*码了.但现在你说我们不 
该为 Unit 类蠘码.这是为什么？ 

: 在項目的这个阶段. 你必埙 

持读问的问*是 •这会 减少項目的风 
隆 • 马？ - 如策答案是肯定的，就应该 
做； 如果答 案是否 定的.可能就可以 
把该項工作留待項目的梢后阶段去完 
成。 

在 Board 的 W 子中.我 们需要 对游戍 
棋4在做什么有个基本的了解.因此 
我们进一步編写基本的实现. 扭是对 
Unit 未说.取得类 B 以及 y 解它的基 
本功能是所有我们真正需要做的事。 
在这两个《子 *. 我们都是在戒少項 
目的 M>Ht. 而不是把焦点放在到底要 
不要*特定类 或包编 妈上。 

I ®): 但是我们不能只为 Board 做 
一 个类图就好.像为 Unit 所做的那样 
吗？ 

^ : 你或许 T 以只做一个类田， 
它真的是你的主 *1 判断 （judgment 
call). 只要你觉得你的焦点是减少項 
0的玖險.辱么到类图为止或 者要更 
深入一姿也都无妨. 


I ®):问客户与用户关于系统应该 
做什么的问題真的是好事吗？他们不 
会让我们走入歧途或分心珥？ 

^ : 问 S •户遏 常是个好主意.因 
为你在构建的是他 n 的系统 。的确. 
彀如你不确定你应试做什么的活.客 
户总是会使你困恚或 it 你去做错误的 
亨，只要就你们的 fj 标为何进行清楚 
明了的对诂，并昱仔*«聆听莱《具体 
事項，你就应该能够过*掉那*让你 
离开正途或分心的事. 

I®) : 我还是不碥定我会自己想 
到使用 Map 来存傭 Unit 类中的各个特 
性。 

^ : 关系.邮是共同性与架构 

三问这类工具的0的.它们«你取得 
你可能自己想不«的解法，而且是放 
诸四海而皆准.适用于各种类 S 的項 
目. - 
在 Unit 类的《子中.重点不在于我们 
以 Map 存鍺 特性.而是我们想出所有 
的战斗单位基本上只是一个战+单位 
类 S (名为 * lype ' 的 String ) 以及 
一 to 名/值对（名为 " properties ” 的 
Map ) , 一旦我们想出这一点，如何 
存些名/值对就只是小事_桩. 


I ®): 那么.实际上没有多少程序 
代码牵涉到 OOA & D . 是吗 

: OOA&D 跟編写代码有 
绝对的关系一它是关于•每一次都 
写出你大软件 " 的事 . 然而，写出良 
好《序代码的方式并非总是坐下来并 
马上 开始編写它。 有时候.编写伟大 
« 序代码的最任方式 . 是在尤许的•清 
况下将《净代码的編写往后礪 li. 规 
划，组织，架构 . T 解需求.減少成 
险 …… 事 ■ 实上 . 这*全却会让你的编 
码工作变得很 « 单 . 

有时候，编笤 

伟大移/?代碚 

况 r 将移序代 

顺延。 




抠任作者 

动。《是»7來. 对此 问屬你金做什 
么7饽的任务* 概述本 « r * 几荧 
的* 容.拜 h »» 如何 sta 
最后达一 令兵繾 功能。 _ ^ 






什么意思？ 
问窖户艰。 


当你不确定项功能的真正意义为何时， te 4 f 的解决 
方式之 询问 客户.我们以此方式解决了 -游戏 
特定的战斗电位-的意义，因此我们以相同方式找出 
“协调移动"的意义是什么。 < 






2. 艿伺性穸祈 


规在傲一些 共同性分析 

接 T 来，你必须想想第366页中客户一直在谈的各种移 
动场 S 的共 N 之处。 有一些适用于各种移 动龙喂 的某本 
唞物吗？假如你认为有的话，在下而的空格中写下那咋 
共间的事 物： 


那么， i 现在要傲什么？ 

假如你知道•协调 移动” 的意义是什么，并且知道所有 
游戏之间的共同 4f 物是什么，你就应该知道要对此游 
戏系统框架做什么，好让这项功能运作。在下面的空格 
中写 K 你的 想法： 


你釦遂“协调移动”的意恩 
是什么蚂？ 

聆听客户应该已经让你对 Gary 的游戏系统抿架的第•： 
个关键功能相3多的 J* 解.在下面的空格中，写下 
你认为该功能 的离止 意义是 什么： 


相相时， ㈣ 料用 ( j 三个 


沩洵餐户 


Islgi 財拌 3 淌塔 l-frmi£ 
热&器？ 


铒益器 3»><-^ 耷？ 


实珙计划 



达里布什么是共罔的码？ 

这里是根据 Gary 的客户关于移动的谈话内弈，我们认 
为黹要做 的事： 

a 斗荤但在找 的一个 方格移 
刼利男■-个。移刼4蕃子釾«或游戏昶定— 

的《法的.有时也含#涉利••游戏轉金的~~ 
a 斗輩佳~ 的鴉性。 ~~ 


所以，在所有可能的不同移动场 s 中的共同性是什 


么？还记得我们的客户是怎么说的吗？ 



ft 么是共同的？ 

计么是 変化的7 

稃动 ffl 布 个检金 会潘* 法 
移动 as 正碓。 

«子每个游戏的检金桴动含法 

性的 s 法是不闳的。 ，— -s 

a 斗* a 的特性拈 
飧战斗* a 能走多达。 

用子毎个遒 戏的特 性乌数1是«— 

不尚的。 郎 

» 3 故斗 * tti 外彩响《 

r * 劫的 © t 。 

彩 _栘动的©*对子《令》 〜 ) 

戏®畜是不《的。 



这*的華户 i 
rt 用 W 被方. 


368 第7章 




就是“对毎个游戏不罔” 

你看到什么东西持续出现在我们的表格里了吗？毎 
当我们找到某种共同性，在变化性的字段中躭出现 
同一 些词： 对毎个游戏不同， 

关于功能，当你发现 不同之事 比 相同之事 还 
多时.可能就没有一 f 良好.通用的解法。 





l ' 5 ) :这真的是跟游戏特定的战斗 
单位不同吗？ 

^:在处理战斗单位时我们确实 
找到了一*共 同性： 每个战斗单位有 
一个 type 与一<«名/值对的特性。处理 
移动时.每个单《的游 戏似乎 会以不 
同的方式处 《. B 此把 移动留 给游戏 
设计者似乎很合而不是想出一个 
看似通用 <2事实上毫无哿助的解法。 


I ®): 不过.还是有 一些共 同性， 

不是吗？移动算法以及检查移动是否 
正确，没错吧？ 

^ : 没錨.那么.理论上 

你可以编写一个 M ovement 接 
口，内含像 mova (> 这样的方法， 
它接受 MovementAlgorithm 与 
LegalMoveCheck , 汉如你想到达如此 
类的事.我只能 《■ -« 真内行！ ••你 
在这场游呔中取得領先了， 

但是接着问你 A 己： 这实际上会获 


得 什么？ 游呔设计者将必《学习你 
的接 o , 假如他们没有正确性检 
查的需要.他们可*传入 null 给 
LegalMoveCheck 作为参数.而 
MovementAlgorithm 接 口 看起来又 
会如何，以及 …… *. 事实上，你可 
能正在增加1杂度，而不是在戒少复 
杂度， 

你的工作是戒少风汝与复条度.而不 
是增加，我们决定让游 《* •设计 者处理 
移劝，并丑只是在棋4上改*战斗单 
位的位夏（使用 Bo«rd 上的方法.这 
一点我们螭实已经处《了> . 
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伟大程序代码与伟大软件 


麥户>为伟六 
桟;？代碚付捃 
你锬，芮是为 
侔六轵件付绘 
你欸 a 


«»。 *4«meK« 3 _小» 4 
紙，上头打7几令勾 *5. 凡个«们知*«由 
牵完成 W* 认 A-«llMl©。 《法《«达 St* 
-你 StfSfl! 大》件的方式碼？ 


绝对是的！记住，伟大软件 
不只是伟大 程序代码。 _ 

伟大程; r 代码垃设计良好的，•胶而 
宫， 会像 它应该做的那样运作。 m 坫 
伟大软件不只足设计 良奸， 它还会彼 
准时交付并 H •做客 户要它做的亊。 

那足架构所关系到 的事： 减少延迟交 
付软件或者不按照客户要的那样运作 
的风险。我们的关键功能列表、类图 
以及那些部分完成的类全都有助于确 
认我们不只是在开发伟大程序代码， 
也是在开发伟大软件。 
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架构 


滅少 风险 布助子伟大软 
件的编写 

处理完•:个关«功能，我们已经掌 Wf 项 H 
进行的上要风险_苻石•我们在本琪所采取的 
H •个步明址如 H 减少 项日风 险的： 


frary 的遨戏系统枢架 
兵铍功能 

一系眈的本«。 


林定的 a 斗攀 a — 系坊的 ♦«. s 达*«•幺*»? 
、**^»»动- 达•么* S . «* 们如《*7 


iii &峩们孖诒 的砲方 
们知迮 ㈣ 构4(十 4 .⑽， 
rtC 外. 一乇 闭悉。 


我 (H 巧 Bmw s 出赛类，任 
• 0 ■蝤 SS5 本的《 4代场皋 
滅少* 事户#的《盎4浮 


T - # . «<ns 也 
-濟戍 鹑金的战斗* 
(2 -的金义 i 6 何.斿 

如何 il«i 雀 功钱. 


5后. fi 用共阉 fi 分 

«. 5 « # i # W 4 l « 
的攀 . a _ 个 i 4 
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要点 


架构帮你将所有的图形.《划及功能列表转化成 
井然有序的 （well-ordered) 应用程序。 

系统中对項0最重要的功能是在架构上甫要的 
(architecturally significant). 

聚焦在那些表示系统的本*.你不确定其意义为 
何以及不清楚皆先要怎么实现的功能上. 


在项 R® 构 阶段. 你所做的毎-件 事邯应该减少 
项目的风睑. 

假如你不痛要用例 的所有 细节.编写详述软件能 
如何被运用的场*可帮你快速收集好黹求， 

当你不确定某项功能是什么时，你应该询问客 
户，然后试着把答案归纳出来，你会对该功能取 
得良好的理解. 


运用共同性分析来构建具有灵活性的软件解法* 

客户对做他们想要之事及准时交付的软件，远比 
对你认为程序代码写得很酷的软件更®兴趣。 




OOJ&D 填字游欢 

继续进行填字游戏.你已经获得所柯的答案了吗？这 
m 垃另一组提示，帮你把所冇这畔架构信息永久存储 
到你的大脑 



横排提示 


11- Use cases odd risk when used at this time. 

12. The essence of a system is whot the 
system is ot its most . 

13. Focusing on more than one feature ot a 
time does this to the risk in your project. 

15. Use this type of analysis when you're not 
sure how to implement a confusing set of 


features. 

16. Architecture highlights these parts of your 
application. (2 words) 

17. Commonality analysis is one path to this 
type of software. 


竖排提示 


1 Always start a project by focusing on this. 
2. The second Q of architecture is about the 


_of a feature. 

3. The first Q of architecture is about this. 
A. You focus on key features to reduce this in 
your project. 

5. These are a way to get basic requirements 
without the detail of o use case. 

7, This is not the some as great code. 

8. You usually trade off flexibility for this in 


your project's design. 

10. you use architecture to turn a mess into 


this kind of application. 

M. You write this type of software the same 
way. whether it’s a big system or 。 small one. 


















g 设 i 十原則 


原创性被高估 



模拟是避免做傻事的最佳方式。 没有事情比困扰你数 H 的难題 
被想出全新且具有原创性的解法更令人振奋——直到你发现早在你之 
前就已经有人解决过同样的问埋，甚至做得比你好。在本章里，我们 
会看看一些人们已经想出好些年的设计原則.以及它们如何帮助你成 
为一个好的设 计者。 先把按照你自己的方式做的想法放一旁，这一软 
是关于以更好.史快的方式做. 
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设 计原则 犬*含 

到0前为止.我们实际 t 一直把注意力放在开始为应用程序 
编码之前的唞愔上，如收集黹求.分析.编3功能列*.给 
制用例图等.当然，在某些地方 你真的 必须编写一些程序代 
码，那是设 u •原則 真正开 始产生作用的地方。 


设计原则是能被应用到设计或编写程序 
( 傾巾的 I 具紐术， it 餅代码更可 
乂*^维护.更具灵活性或者更易扩展。 


在稍早的章节里.你已经看过一些设计 原則： 

00 琢則 

«装4«=物。 

时 aortit . 茶不4的4现。 

在用《4中的* _个龙. 0 •有-个畋変 
的 JI* 


俱芹&祺证宍的 
00珙计#则矽成 
其可维护、真具灵 
渚性!^及 真易扩 
屝的轵件 .， 


在本孝.我们会冉看看儿个重要的设计原则，以及毎一个设 
lf - K (刖如何改#程序代码的设计与实现，甚至会看到有■候 
你必须在两种设计原則之间进行选择。让我们从本饫的第一 
个设 U * W 則开始吧。 







设计原则 


原則 *1: 

开闭原则 (OCP, 

Open-Closed Principle) 

我们的笵•个设II•原 则坫 OCP, 或称为 汗又 •原則。 OCP 完全 
关系到允许改变 （allowing change) ,忸足以 不需要 修改现 
有程序代码的方式 进行。 这里是我们通常定义 OCP 的 方式： 





开闭原则 （ OCP ) 

类应该允许为扩展而开放，禁止为 
修改而关闭（译注 1) 。 


禁止为妗改而兵闭…… 

假设你有个类具存特定的行为，而且你已经以想要的方式 
为此行为完成 f 编码。确认没有人能改变该类的程汴代 
PJ. 汴 ail： 此行为的特定片段禁止为修改而关闭 （closed for 
modiHcation) ,换句话说，没有人能改变此行为，因为你已 
经将它 封锁在 确定不会改变的类中. 


嗜由不尤锊《何人边仿•坏 
(close) ft ； 



…… 侄允许为扩展 而 孖放 

然后假设某些人出现，他们就必须改变该行为。你真的不想 
让他们弄乱你那完美的程序代码（它几乎在所有情况下都 
运作得很 好）， 然 iM 你也想让他们使用并扩展你的程序代 
码。 所以你让他们扩展你的类，于是他们便能以他们想要的 
方式覆盖 (override) 你的方法，因此，即使不弄乱你那完 
羌的程序代码，也能让你的类允许为扩展而开放 (open for 


[ Conm^ n II 

0 

p 

EN| 








还 KdRick 的弗乐器吗 ? 

你当时吋能不知进，然而 S 我们为 Rick 的弦乐器编写那些 
Instrum « ntSp«c 尨时 （第5联），我们确实运用 /" 开闭原 

mi： 



/子«电2的郝分从 
爱中礎时装 * 乘 .j 


加一螫《朴的《的* i* 來公《沐8 
«4Wsf¥, 


InsinjmeniSpec^jbj^i^^Cjff 兴拥； 
^maichesO ^ 法摟定久在基炙中 

^xyr^^ a 

伍是它允许为 r 展芮扞故,因为所有的孑夷可 


•玫变 mdch ^ y () 的行为。 




设计原则 


OCP , 一步一步采 


让我们 M 忆第5萑所做的亊，以 OCP 来#看它，一次--个步 

睞。 

❶我们为 InstrumentSpec . java 里的 matches () 编码并且禁止为修 
改而关闭它。 

m«tches() 的这个版本运作得还不锫，我们不想让任何人弄乱它。换 
言之， .H 我们完成编 InstrunantSpec 以及此版本的 match*s<). 
它们就不应该再改变。 


model: String 


getBuilder(): Builder 
getModel(): String 
gelType(): Type 
getBackWood():Wood 
getTopWcmdO： Wood 
malches(lnslrumentSpec): tx 


这个方•: tii ⑽祕. 


O 但我们需要修改 matchesG , 以便使用乐器特定的规格类。 

B |1 ('1； matchM 0为其他的 In » trum « ntSp«c 对 象运 作得很好，但迪对 
吉他与曼陀钵来讲，它并不会做它该做之事。因此，即使 《« t C h«sO 
禁止为择改而关闭，我们仍潘要•种方法来扩展并改变它……否则， 
Ins trumentSpec 就个'适很灵活，这是个大问 埋。 




o 因此我们扩展 InstrumentSpec ， 並且覆盖 matchesO 来改变它的 
行为。 _ 

我们不想改变 InstrumcmtSpec 里的程序代码，但我们可以扩展它，扩 
展成 GuitarSpec 与 MandolinSpec, 接着搜羞毎--个类中的 matches() 
来增加乐器特定的行为。 







OCP 关系到灵活性，而不只是继承。 


无疑，继承是开闭原則的简单例子，但 OCP 
可不只是扩展与《盖方法。毎当你编写有 
效的程序代码，你想要尽力确保它持续有 
效……那表示你不想让其他人改变该段程序 
代码. 

然而.总是会有程序代码需要被改变的时候， 
或许只是针对特定的一两个情况。代#一头 
钱进 程序代码并做_•堆修改， OCP 让你扩展 
你的有效程序代码，而不是改变当中的程序 
代码。 


有许多不同方式可以完成这件事，而继 
承通常是最容易实现的，但的确不是唯 -- 
的选择.事实上，在本章稍后谈到合成 
(composiiion) 时，我们将会 W 论实现这件 
亊的8—个好方法。 



设计原则 


I 你的铝 t 

寻找你自己的项目中的 OCP 。 


想一想你0前正在做的项 EJ, 你能找到任何已经使用 OCP 的地方吗？如果有的 
话，在下面的空格中写下你是如何使用 OCP 的， 


现在，在你的项目中找出一个应该使用而未使用 OCP 的地方，然后在下面的空 
格中写下你认为你需要做什么，好将 OCP 放进项目的那个地方。 


1^) : 修改基 类或你已经编写的类 
的话有什么大不了的吗？ 

^ : 一旦有了有效的类并且在使 
用它，你就不会想要动它，除非有必 
要。 fe 是记住，改*是软忤开发中一 
項不变的真理。使用 OCP , 我们尤许 
通过扩展而改变，而不是 © 头修正你 
现有的 C 序代玛，子类能增加及扩展 
暮类的 行为.而无需4乱巳知有效且 
让客户高兴的《序代码， 


I®) : OCP 只 是另一 种形式的封装 
吗？ 

^ : 事实上它是封装 

(encapsulation ) 与抽象化 
(abstraction) 的结合.你正在寻找 
保持不变的行为并 i 将该行为抽取到 
基类中，然后将《序代码鏔住以禁止 
修改.接着. S 你需要新的或不同 
的行为时.你的子4会通过扩系•基类 
来处攻这項改 *。 W 是封装着力的地 
方： 你正在 封装* 化之物（子类中的 
行 为）. 将它与不 t 之物（基类中的 
共 m 行为） 分开. 


I®) : 那么.运用 OCP 的 唯一方 

法是扩展其他类_? 

V: 不，只要你的《序代码禁 

止为修改而关 W, 但允许为扩展而开 
放，你就是在运用 OCP. 例如，极如 
你在类中有一些 'private (私 有） 方法， 
那些方法便是禁止为修改而关闭——没 
有其他《序代碼 ft* 乱它们.《接着 
你可以增加一*以不网方式调用这® 
private 方法的 public 方法.你正在扩展' 
这* private 方法的行为.而 无需改 t 它 
们 .那是 OCP 运作的另一个《子. 


当前位霣— 381 




不自我霣爱 


原则 *2: 

不 t 我重复原則 (m, 

Pow't Repeat Yourself Principle) 

接 "K 来要 h 场的 a 不自我 T(a 原则，简称 DRY 原則.这进 M —个看起来相当简羊 
的原則，但是对编写容易维护及重用的程序代码来说却是常重要的。 

-\不自我重复原则 

IKIY) 通将共同之物抽取出来并 s 干单 
~ ~~y 一地方来避免重复的程序代码。 

运用 PRY 的最好地方 

你已经看过 DRY 原則的运作，即使可能你当时并不知道 • 我们在第2章使用过 
DRY. -1 时 Todd—i-jGina 要我们在狗门打开后让它可以自动关闭 • 



BarkRecognizer.java 
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设计原则 


1 . 让我们拕共罔的程序代码紬取出来。 

运用 DRY ,我们必须先将 R * mot * i-jBarkRacognizar 之间共同 
的程序代码抽取出来，将它放进黾•地方. M 想第 2 ft , tt 好 
的地方躭坫 DogDoor * : 



2 . 现在从其他地方将达段程序代码桴除…… 
$. ……接麝引用步驟 M 的我序代铒。 

第 2. 3 步间时 发生，从其他地方将这段程序代码移除，接笤，有需 
要的话，躭引用特別抽取出来的程序 代码： 


味代 
a …… t*® 

(S^ OojOoot ^ 
冲 《»() 方法令 



戧们 不必鞾 《* if 用# 

® 出来的《存代 4 g . 

这 6 经 由私。 


BarkRecognizer.java 
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PRY 完全兵系到一个 M 方一个 f 求 

抽取出程序代码&运用 DRY 的好开始， （HDRY 的内涵 -I 不只 
是如此.当你 Wft® 免1复程序代码时，实际上也在 Wtt 确保你 
对应用程序中每一个功能与黹求只实现一次。 

在刚刚费到的狗 N 中.我们正试着实现的功能是13动关狗门。 


Todd ^ &ina fet) 狗门 ， te 本 2 .0 
i # f-J 表 

1 . 箱门》0必*至少«12英寸 S。 

2. *坨8上？!«_个《狂。若 D* 关*的.»7| 

ftn. sniff 


<f-amn»trn. t 


基我们奋此轚.值的 

#-t« 0 


原来，我们在两个地方 ( Remote . java ' jBarkRecogniz « r . java ) 
实现该吶一功能。 



这*个方法部节关狗门 
的《序代砝。 


通过运用 DRY, 我们移除®复的程序代码，但更重要的是，我们 
将这 个需求 （自动关狗门）的实现移到一个地方，代替原有的两 
个地方. 


Hopen 。 I ^ 


o 苟二^ ■铋方 t 妨共 
典 0 : OofO^f ttoptn ()„ 



设计原则 


、常闷％® 

% 

I®): 那么. DRYft 不 ft 关系到重复程序代码以 

及®免复制与粘貼 （copy-and-paste> ? 

^ : DRY 关系到避序代码 .fit 它也关 
系«以不会 制速史 多后续问趕的方式进 行編码 .不 
只是把出现一次以上的《序代码去进单一类中.你 
必《确保系统中每一个行为与信息的片段只存在于 
单一.清楚的地方。那样的话，当你的系统需要该 
行为与 tt 息时. 就总会知道去哪儿找. 

I®): 假如 DRY 与需求 和功能有关.难道我们不 
应该把它应用到收集功能与需求上.就像应用到编 
写程序代码那样？ 

^ : 完全 正确. 是个好主意！无论是編寫需 
求.开发用 WA •是鴆写《4代码，你会想碥认你没 
有 *4 系 *1 中的事. 需求座 该只被实现一次.用例 
不 aa 有*全.你的《/»•代碼不应试*复它6己 . 
dry 所关系《的事情 达超过 《序代码. 

I®): 这全是为了避免以后的维护问题吗？ 

^: 是的.忸它不只是避免在一个以上的地 

方史新 C 序代码的需要，记住， DRY 关系到特定片 
段的行为与信息具有单一来源 (single source) ,但 
是，该单一 来源必 《合理！你不会想要以叫 声识刻 
器作为关门的单一来源，没«*&?你认为典门 
应该清求 》) 卢识别 JS 来关 《) 它 ft 己吗？ 

因此. DRY：?； 只是移 除重复《净代玛.它也是关于 
如何产生分解系仗功能的好决策， 


my) 

c > Ry 兴系到 it 系綷中 
每—个倌息与行为的 
片段鞒保存在单―、 
令球的 地方。 
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谀计拼障-—— 

DRY 所关系到的事情远超过找出系统中的*复的程序代码，它也适用于你 
的功能与需求。现在是由你自己将 DRY 付诸干行动的时候了，而不只用在 
程序代码 t 。 

问题： 

Todd 与 Gina 已经为他们的狗门想出更多的功能，你的工作是确认 
我们所组合的功能列表中没有任何 重复的 议题，每一个功能在你 
设计的系统中被处理一次且仅一次。 

任务： 

o 仔细阅读右边的需求与功能列表。我们加了一些新的需求与功能，以 
黑体字表示。 

o 仔细査看新的需求与功能.肴肴在你必须构逮的新事物中是否有任何 
可能的® a ? 

O 为需求与功能列表注释，标示出你认为已 经®® 之处. 

O 在列表底部重芍®复的潘求.去除不必要的® k 。 

O 在下面空白处为 DRY 原則写下新定义，确认你所谈的不只是*复程序 
代码。 

g 含 





不自我重复原则 




设计原则 



- ► »答在 " P - K 。 
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勿*复任何事 


为擗求与功能列农汴释.标示出你认为已经《之处。 

在列表底部重 SSK 的黹求，去除不必要的 重复。 

在下面空白处为 DRY 原則写下新定义，确认你所谈的不只是 S 复程 
序代码。 


珙计拼窗斛奢 

DRY 所关系到的亊情远超过找出系统 中的* U 的程序代码，它也适用于你 
的功能与潘求.现在是由你自己将 DRY 付请干行动的时候 J*, 而不只用在 
程序代码上， 

问题： 

Todd 与 Gina 已经为他们的狗门想出更多的功能。你的工作是确认 
我们所组合的功能列表中没有任何重复的议题，毎一个功能在你 
设计的系统中被处理一次且仅一次。 

任务： 

o 仔细阅读右边的需求与功能列表.我们加了一些新的需求与功能，以 
黑体字表示， 

O 仔细 s 看新的擗求与功能. 看看在 你必须构建的新事物中是否有任何 
能的® a? 


安下伐< 16 的 DRyes 定义 


不自我重复删 

IftUil / PRY 兵系到让系敁中每~ ~个 

- ./ « 患乌行为的衿段« 保矿 

V 在单含 aww 方。 


o o o 
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设计原别 



4我 n 釦坷豸合_ 
鸟重写 t 求#6鸟#9 
W 方式。 


Todd 乌射 wa 的 W 门， life 本？ .0 
t 求乌功 陡列老 

1. 昀门孖 ns 少 S 布 12 英寸*；。 

2•埋拉器上 p , 布一个按饪。 sn 是兵*的，垵 
• F 桉纽孖门,若门是孖*的，按 T 桉纽共门。 

3•— E 构门打孖，若 丰狨兵闭. 它栴&动兵 
闭。 

冬 叫声识别器必级陡 ffi 别构的叫芦。 

5. -ft 到狗叫时叫声识别器必•涵打孖狗门。 

6^ SA 佐 子捿近»门.认 s 不 
加以»»«无法打-»时，— 鶉 Dfian 出警 

【昀 n 在 _* s 中的 某些特 定时问应法打孖。 

I . 狗门皮试拈螫含 w 房孑的保安系统中，碓- 
保狗 n 打孖及兵《时不 会触动 髻铃。 

9_«如典门® 重外 牌磚貉《死法 打孖， 梅门 
紐省*声料衫 。 

10. 构门应淡進踪构狗一天进出多少次。 

II. 假如在狗 n 打孖之前保安系法 a 打孖的， 
邡么 s 狗门打孖时保安系统 s 法重启。 


滔如布室沟或 t 外的»«?粕 ® 换狗门的埭作， 
构门 s « 警丢主人。 

s 昀门打开.保安系统会®除：当典门兵闭. 
保 S 系陡会重后 （® 如佴安系法是打孖的 
话）。 


这霣的 
# # 对41 


* #»8*»<丨署 ♦« 

S ■佴《 #•谈尹乒. 6 1 
们真的也 i * C ® 筝冬 | 
劝《作的重4 


t * 
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单一职责原则 

原则叼： 

单一职责原则 (SRP, 

Single Responsibility Principle) 

SRf •完全关系到职教以及系统 ift 哪个对象该做 什么。 你想要你所设 U •的毎 
-个对象都 H 聚焦在一个职责上——当有关该职贵的某件事改变时，你会 
知道究竞去哪里改变你的程序代码。 


S 单一职责原则 

系统里的毎一个对象应该具有单一职 
1责，所有对象的服务都应该聚焦在实 
__现该职责上， 



当你的每—个对象鞒芒 
有—个玖奕的球由时， 
你巳经 JE 碲地宍现单— 



390 第8章 







设计原则 
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SRP 分析 


找出多重职责 

大多数时候，你 -I ■以利用简单的测试找出来使用 SRP 的类： 

O -张纸上写下几行像这样的 内容： The 【空格 I I空格1 itself (译注 

2). 对干你正在测 K 的 SRP 的类中的每 ■■个 方法，你应该邯有一行像 
这样的内容_ 

o 在毎一行的第一个空格中写下类名.在第：个空格中写下类中的方法 
之一. 

o 大声把毎一行读出来（你可能得加一点字才会好 读）。 你所读出来的 
内容合理吗？你的类真的具有该方法所指的职责吗？ 


万一你读出来的内容 不合理 ,你的方法就可能违反 



392 


► 译注2:在中 文中. 此行文字可«|空格 || 空格丨它 il 己 （若 第二个空格冉及物 
劝 : 或 者是： *|空格丨6己丨空格丨 （若* 二个空格为不及物劝岣> . 





设计原则 


lj 尖你的铝笔 

^ 将 SRP 运用到 Automobile 类。 

Automobile 类的 SRP 分析 ft 示如 T. 为下表填人 Automobile 类的名称 U 方 
法，如我们在上 一tf_( 所述。接着，判断 Automobile* 具有的毎一个方法尨 
否合评，然后勾选右边的方格。 


我们«蓽 5 *中的 
_ 00大■史堆+■中卷 
过这个爱 t 


start() 

stop() 

changeTires(Tire [*]) 

drive() 

wash() 

checkOil() 

getOil(): int 


、 J 的.朗他㈣㈣… 
倚看 -下. 疼后 4© 到这凡作 I 
任簡糾 你. 

光 t S 琏 g. o 有 4 的歧_卡沒- 
辦激的 
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SRP 分析: 


^utomobde 




itself . 

- itself . # 

- itself . 

. Itsel 长二^ 
— — itself . 

山斗 卜 ， itself . 

，十 】 oil - itself . 


»■•!*{** <f 

*= a- 

* 个字 . it ® 
子镇 起來 a * 


■<«***i*] 


■%i 9tf. ^ it 
耷体 i. 乐合 
S . 印 4 it 赛 
的 rttST — 


: 't 4 (5 # t 
5^^%. f# - 

:龙 t S 琏 tl S 




的铝笔 

解答 将 SRP 运用到 Automobile 类。 


Automobile 类的 SRP 分析 SL 示如下 • 为下衣填人 Auiomobilc 类的名称与方 
法，如我们在上•页所述。接猗，判断 Awomobile 类具有的毎一个方法是 
否合理，然后勾选右边的方格， 


饬在找6 径仔紅 s a 这 - 魚以及 
■»«!- 4 ft 么砉 S . 这只4 - 个达® 

•:中;？ 油蓍的方法 . 

在 ii « 的寧。 


认 «s« . ^ ^ 

€苟机的贵仔。 





£ C 6 € 6 6 6 

rhrhrhrhrhrhrh 


0 8^$^o f 

«• 

ssyrQrQOQOort 






设计原则 


从多重职贵到单 一职贵 

- U . 完成分析，你 - I •以将不应该保存在类中的所侖方法移 
到负起特定职《的类中。 






7 * t* $. 



、術 匈超 


I®): 当方法接受参数时. SRP 分析如何运作.像 

CarWash 类上的 wash(AutomobMe) 那样？ 

^ : 问得好！为 T 让 SRP 分析合理， 你需要 将方法 
的参彀&含《方法的空接（即*二个空格）中.因此， 
你会写成 "The CarWash washes lanl automobile i(self. ■这 
个方法合 《 (♦有 Autonobil •参 数） ,所以它会留在 
CarWash 类中. 


: 但是.万 一Automobile 是 CarWash 的构造函数 

的部分参数.而该方法只是 washO 呢？ SRP 分析会不会给 
你错误的结果？ 

^ : 是的，它会，彀如可能让方法合理的参数（如 
CarWash 上的 waah 方法的 Automobila) 被传进构造兩 
敝中.你的 SRP 分析可能会*导你.18 邶軋 是为何除了从 
SRP 分析所获得的 tt 果之外，你总是需要运己的常识 
以及对系坑的认识的原因。 
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设计原则 


你认为 SRP 如 M 被用干 Todd 与 Gina 的狗门？在卜—面的空 白处写 下你的 答案： 


现在看看你是否能在本书到目前为止的范例中找出两个实际的例子，来说明运 
用 SRP 让我们的设计更好、更灵活 • 你能在 Doug 的狗门. Rick 的乐器库存 
搜索器或 Gary 的游戏框架里找到 SRP. 写下你找到的毎一个实例以及你认为 
SRP 如何被运用。 

第一个实 

范例应用 程序： _ Rick 的乐器_ Doug 的狗门_ Gary 的游戏 


SRP 如何被 运用: 


ST_ 

在 ii 个 W 孑中 _ 

用。 

第二个 实例： 


_ Aii 角在个铯 

_ 制6用《璆中. 



范例应用程序：- Rick 的乐器_ Doug 的狗门_ Gary 的游戏 


SRP 如何被 运用： 
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设计原则 



你认为 SRP 如何被用干 Todd 与 Gina 的狗门?在下面的空白处写下你的 答案: 


«们《其鸚门代铒从 中移 捋 Bg 免在 
farkgttoiwiztri 布 aa 的 a>» 代<8 (rey 在此 产生玫 》! > - 典们也 
« a « PoqPoor 类门布兵的》布»作——€算<»—的职 a „ 

现在看看你是否能在本书到目前为 lh 的范例中找出两个实的例子，来说明运 
用 SRP 让我们的设计 g 好.电灵活。你能 ft Doug 的狗门. Rick 的乐器库存 
搜索器或 Gary 的游戏框架里找到 SRP。 写下你找到的毎一个实例以及你认为 
SRP 如何被运用。 



这 r ?的 
* SRP (套 
DRY ) 釦叼珥 
我 <n 赴5角 


第--个 实[列： 

范例应用 程汴： ZRick 的乐器__ Doug 的狗门_ Gary 的游戏 
SRP 如 M 被 运用： 

我在 IwitrumeHtSpec i ： frUtmatehesO 方 ife. « 不墨》比《乐 a 的 fflff 代 c *;iiA SRP l ' A *- 

«8 « 绐 Inventory ♦ « search!) 方法。 ®*t. IwtruwentSpee St a 兵子乐 8 '.u h ? ?. <4 i ^ ^ 

«« 的苺 一件幕 —— *t 段 flff 代铒不 WB«X 铯的 * 中： SKP 在迗 si v). ^ 

— 

第二个 实 gl: 


范例应用程序：_ Rick 的乐器_ Doug 的狗门 Gary 的游戏 

SRP 如 H 被 运用： 

g 典们在 U nit Map a 斗蕈 性封 .典们 ftta 

SRP, ©rt, 代《 让游戏特定的 Unit S£Jie(nWW«, 
jiita 不间 aw««, 我们拕 所有乌 ««««的功能性 »s，iunif 
* 中。所 ()C 与«性《兵的功陡在攀 一w 方被处 U ― Unit*。 
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原則 *4: 

liskov 替換原则 (LSP, 
liskov Substitution Principle) 

接下来 《 场的设 IHfi 則是 Liskov# 换原则，简称 LSP. 它的定义是很简单 
的： 


V - !~ Liskov 替换原则 

子类型 （subtype) 必须能够替换 
Vy 其基类型 （base type) 。 




LSP 完全关系到 设计良好的 继承。当你 
从一 个基类继承下来时，你必须能用你 
的子类替换该 基类且不会把事情弄糟. 
否则，你就错误地使用了继承（译注3>。 


设计原则 


孑类化的 误用： 

误用继承的案例研究 

假设 Gary 有位新客户想要使用他的 GSF 以创达 World War II空战 
游戏，他们需要扩展*本的 Bo«ird 坫类型，以支抟 3D 的棋&来表 
现天空。这甩是他们已经做过的事： 


Board 

width: int 


f ft &的 蓁 

!t«o 



tiles: Tile [•][•] 


getTile(inl, int): Tile 
addllnit(Unit, int, ini) 
removeUnit(Unit, ini, int) 
removeUnits(int, ini) 
getUnits(int, int): List 

0 


它坩加 一典* 方法 
來支祷 30 t 钤。 



getTile(inl, int, ini): Tile 
addllnit(Unit, Int, int, int) 
removeUnit(Unil, int, ini, int) 
removeUnits(int, int, int) 

、 getUnits(int, int, int): List 




Moke it Stick^aK 

这《事情全 《 相似. 

使用 * 类*者它的子类不籩一件伤黼霱的事. 
取代. 交換鄒不成闷麵. 

它们全«—祥.全《使用 LSP! 


- 401 



LSP 摴#继承结构 
所隐藏的问题 

乍看之 F, 子类化 Bo«rd 以产生 T •类似乎是个好想法， 
然而 ff •细# fi, 这个做法会产生不少 问题： 



所以此设计违反 LSP, 的碎用 -: 去 . 



“孑类型必颔能替换 
其基类型” 

我们已经说过 LSP 规定“子类型必须能锌 换其* 类型 •. 
供这到底是什么意思？在技术上，那似乎不成 问賊： 

Board board = new 3DBoard(); 

T 

U 鰱 i 畢 S 的 视 .€ * « . 

306 oatd fi ij s g 用来 K 
rt Bond, 

然而，当你开始真正像使用 Board —样来使用 3DBo a rd 
实例时，事情很快就会变得令人 困惑： 


Unit unit = board.getUnits(8, 4); 


¥ 


因此，即使 3 DBoar<l 坫 Board 的子类型，它也不能替换 （耷 0SP) 相•子 8 0 «<(£ 的《何方 

Board 3DBo«rd 所继承来的方法不具有与它们在父 法 6 破用 <5 SDBo-di …… 表畎 

类上相同的意义。 共 至更糟的娃，这些方法的实际意义 ^ oecdssw . taeo ^. ;a««f3t5)« 



关系， 
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避免令人困想的程序代码 


逋反 LSP 造成令人谬惑的程序代码 

这肴起来似乎没什么大不了，然而违反 LSP 的程序代码会令人闲惑， 
也坫 ifflWT 作的梦我们来符符某人第•次使用设 11 •不良的 3DBo«rd 
会如何？ 


他"丨能从检丧该类的方法幵 始: 
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误用继承的程序代码 难以理解 。 

使用继承时你的子类从它的父类获得所有 
的方法，即使你并不想要那些方法。假如 
你错误地使用继承，将会得到许多你不想 
耍的方法，因为它们可能令你的子类不合 
理。 


那么你该如 H 避免 这种怙 况？首先，确认 
你的+类能取代其*炎，也就蛙进循 LSP。 
其次，在你的程序代码中，运用一 些继承 
的替换做法…… 







解决 5 时 oard 的 问超 : 
f 使用继承 

知进继承不玷解法并不够……现在，我们必須想出应该做什 
么，让我们再来召 fi-Board U 3DBoard.>fc, ##我们如何不 
使 ffl 继承，也能创 it3D 棋盘。 


设计原则 




妒畏 （《««,‘„). 哉们值用 
ME( ( * ts<,e,4t, °") . SUb 3 DBca,J 
9 以後用 B 。- 咐糾. *7^4r« 
6. u.xiiAi.sp t 


给心 n 核 4 托 


addUnit(Unit, int, int) 
removeUnit(Unit, int, int) 
removeUnitsfint, ini) 
getUnits(int, int): List 


zpos: int 

3dTiles: Tile [Tin 


3DBo«til g W •饵锌 _ 
i0Bo«*<l 的象.蕞后 
I (?|.)««的30» 含 

I (coUtction) 。 



mat ow **〜 oiO 的衫 
式 3 DBao »< 炎坫它的供多幼 
ttft 凌托飧个利的 


迖螫方法«« 來很译 B 01 m (中的 
is it . (S 它 mtl 值用 e。 ■^中 
的行.，因 

rt. 


除继承之外还布 计么好 迭择？ 
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使用另一个类的功能性 


将功能性委托绐其他类 

你已经知 * 委托是一个类将做某寧的任 务委派 给另一个类.它是 
继承的 几个替 代做法 之一。 

. 

委托 a 将特定X作的责任 娄派丨 
VkI 给另一个类或方法， 

—敬— . 


委托是我们刚刚用来解决 3DB 0a rd 问题的方法，没有诉诸继承。 
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设计原则 


何时使用委托 


委托婊好在你想要使用•个类的功能性时使用.依照原样，完全没 
有改变其行为. ft 3DBoard 的例子中，我们想®使用 Bo«rd 类中的 
各个 方法： 



因为我们不想改变现有的行为，但我们又想要使用它，所以我们可 
以简申.地在 SDBoardfj Bo«rd^ 间逮立委托关系 • 3DBo«rdfr 储多个 
Bo««l 对象的实例，并 R 委托与飪个单独 Board 对象相关的工作， 



托琀以中 W 方: •在. 


假扣侪霈要谀芹另—个类的功炜惟，但 
>想玖实 该功邾惟,考虚％爹托代暂继 

诼。 
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使用些 ( composition ) 将来 f 其他 
多个行为集含起来 

冇时候，委托不是你需要的东西。在娄托中，你将行为委 托给另 一个对 
象，该对 &的行 为不会改变。 3DBo«rd 总是使用 Board 的实例，而且 
Board 的方法的行为总是保抟不变. 

然而在«些情况中，你需要一个以上的行为以供选择 • 例如，假设你想 
要开发 Weapon 接口，接着创建一些此接口的实现 （implementation) 且 
它们的行为全都 不同： 



prop*rtieWftMapiK 的特性之一将是 "weapon" ,此特性的值将适 


Weapon 接 n 的实现 • 但是 Onit 可能电换武器，因此我 (f| 不想把 weapon 
特性绑死在特定的 Weapon 实现上,相反，我们只想让毎个 Unit 能够<31 
用 Weapon. 不论我们想使用哪一种 Weapon 的实现 • 


咐中.《个转^ 


我们不 SA 娜<3 筠定的 «器 
£……和 A . 裁们 
的武器奕«=：问进«洼》- 









设计原则 


何时使用组含 

当我们引用的行为时（像在 Unit 中）， 我们使 W 组合 
(composition) . Unit 的 w««pon 特性 垃山 特定的 1to«pon 实现的行 
为组成 （composed). 我们可以 UML& 示它，如下： 



ii . 合豕 114 合 ■' 


当你想要使用由接口所定义的行为，并且从该接口的种种实现中 
进行选择时，组合是 ft 有威力的，不论是在编译期间还是在运行 
时。 


梦 


组合 ii 你使用来自一组其 
他类的行为，并且可以在 
运行时切换该行为。 


备神 7阄描科通成， 


<5人泌 ii*® 寧喵，1 
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组合与所有权 


, 箱料也就浚 J …… 

关干合成，我们还有.个®点没提到。矜对象 iJiK. 他对象 
组成.当拥有对 fc (owning object) 被销》时,被拥有对 ft 
(BII81 介的一 郎分） 也跟打消失。 这私 点令人困感，所以让我 
flNSEff 细地 ©Sfll; 到歧珐什么意思。 


这电乂足我们的 Unit 类，它对 Weapon 接【1与其实现 具冇合 
成 关系： 





(context) d 



^ .子 * 伐在 t > 刼 ⑽ 
~英 联的 SwOTii 的 g 


► iHi4： 这*璉立 A ■•人在到在，人亡 到亡- 的提下.若0如此 
(例如.人亡之后另一个人可以捡起到《飧使 . 则可 
改用® 合关系,， 
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设计原则 


在组含中，由其他行为所组成的对象 
棚布 ( own ) 那些行为。当对象狨摧 
銳时， 其所布行为也狨楢毀 ( » a?) 。 
姐含中的行为 不存在 子组含本身《_ 
外。 ——— — 
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聚合行为 


聚含： 组含，但浚有突然的 
结東 

当你想要组合的所有 if 处一选择行为的灵活性以及坚持 
LSP. 徂你的被 31A •对象 (composed object) 盅®存在于 
主赛对象之外时该如何?那正是聚合 (aggregation) 着力 
的地方， 


聚合是3—个突 被用作 >i .个15的 
部分时, W 仍然 -J 以存在 fit* 之外_ 


杏孩 鲐中的在於香《努 
必饬 咤宠鲁《船时 .* 

&ji 。 




合邻#- Stt 合对象 （composing object) 

被摧 Jl 时. 其所有被 tt 合对象 （composed 
object) 也很着灰飞烟天， 
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设计原则 


组含 vs . 聚含 


问时该使用组合.何时该使用*合，是•件很容 au： 人困惑的 
唞.把这件郸_# 沾楚 的垴简笮的方法躭坫问你自 ••这 个我 
想使用其行为的对象存在子使用其行为的对象之外岬？ ” 

假如该对象 <行为被使用的对象）确实独立存在，你应该使用 
聚介，假如不是的话，就选择组合，但是要小心！科时候，在 
对象使用屮的轻微改变也会产生全然不同的结*。 


atego ^ p 少年亊件薄 

——栈序珙计饰泛涓宍的务穸 

Joel 靠在椅背上，看着下班后空荡荡的办公室，他的嘴角微微上扬，布满血绞 
的双眸正闪动宥一场美梦。 Joel 的 心里盘 算肴，一旦公司的股* t 市，他就要 
买一台全新的 OSIM 按摩椅， W 到南太平洋 _h 的热带岛屿体验一下热情的比* 
尼。游 戏程序 设计是…项苦活儿， ifti 今晚， Joel 又是最后一 个典开办公室的人. 
"人 _ 们即将为 «Cows Gone Wild» 疯狂”，他心31想教.拿出 Gary 
的 GSF 使 HIT •册. 开始 .ffi •考如何实现牛仔 （cowboy ). 他必 
1 须处押的錄后 -项功能。突然间，他的眼.拓，掙驻在 Unit 
炎 .h, 他明 £) 他 "f 以将 Unit 用在牛仔 h, 将 Weapon 用在套索 
(lasso ) ,左轮手枪 ( revolver) K 至格铁 （branding iron ) 上。 

Joel 创建了 Lasso、Revolver. Brandinglron 类，并确认它们全都可以实现 
Weapon 接口。他甚至将类型为 Weapon 的特性添加到他的 Building 类中，因此 
在追逐牛群的漫长一天结束后，牛仔们可以将装备挂起来 • 

“真是妙战……一点点组合，我相信 Brad (老板）将让我担任游戏领域的首席设 
计师。”他很快将他所做之事绘成类图留给早班人员，并在 Unit 与 Weapon 类之 
间画上带有实心菱形的实线来表示合成关系.他随即前往回家路上的 Taco Bell. 
买份玉米面肉卷，再来点可乐，好好慰劳 -- 下自己 s 

然而 Joel 不知道第二天上班后等候他的不会垃 Brad 的褒艾，而 垃一顿 怒斥. 

Joel 到底哪里做错了？ 
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继承 只是迭顼之一 

在这 .is. 我们从 LSP 以及子类必须能林换 Jt 基类的*本 
想法开始淡起.然而9£敢要的迠，除I■继承之外.你现 
在冇化种方式 "T 以* HI 来 ft K 他类的行为. 
lh 我们快速来 ft 抟他龙的行为的选项，无需诉 it! 
子类化 (subclassing) „ 



委托 (Delegation) 

当你不想改变某行为，而实现该行为不是此对 
象本9•的责任时，就将行为委托给另一个类。 


组合 (Composition) 

使川 S 1 合.你可以®用来自•个或多个* 
的 行为. 特別坫来 fl - •个族辟的*的 H 
为. 你的主要 对象 完全拥打被组 合对象 
(composed objects) ,而 fl 被组 介对 象 + 
存在 r •主 要对象之外。 


傢扣你喜渗爹托、 
徂令与棼令胜过 
轉 ,你的轸件 
逯常会 K 炅泠， 
其易维铲、 r 展与 
重用。 



聚 兔 (Aggregation) 

当你想要合成的所有好处，但是也想 要在主 
要对象之外使用被组成对象的行为时，就使 
用聚合。 


这三好 



1^) : 我以为子类化 

(subclassing) 是一件好亊.但现在 
你却说它 是一件 坏事？ 

^ : 不，子类化与*承对任何良 
好的00编《语言而言都是关键,，然 
而 LSP 不是关于子类化，而是关于何 
时子矣化.氙如你的子矣真的可以替 
接它的 基类.厣么》承在此可能就很 
合速； 彀如你的子类不 T 替换它的暮 
类.卑么你可 ft 要看看其他的00解 
法.诹 R 合与委托. 

I ®1 :在真的不应该扩展其他类的 
类中使用委托.组合或聚合都 OK 吗？ 

^ : S 然， 事 实上， LSP 根求 

不适用于类的委托或 聚合， 因为这两 
个是修正不符合 LSP 的继承树的好办 
法. 你甚至可以说. LSP 的良好运用 
与委托.紐合及聚合相辅相成， 


一 超 

I®): 我们真的总是霈要运用 

lsp 才能想 a 这一点 吗？不只是编写 
良好的 oo 软件？ 

^: 很多时候.你不用担心编写 

良好《序的设计* 刻的正 式名称。例 
如，田頟第401頁的 Board $ ■例， 为了 
让 3 DBoard 扩展 Board . 所有的方法 
都必用被改«!那应该就是邁到一* 
抽承问«的析先 （不管你是不是在用 
LSP). 

I®) : 有许多奇怪的 UML 符号存 
在.我该如何记全它们？ 

^: 你真的完全不需要去记这些 

符号。《然 UML 为紐合与*合提供特 
定的表示法，但它们全■部只是不同形 
式 的关联 （ association ) 。 B 此，就像 
我们对委托所做的.你 T 以使用带有 
薄•头的一般实缦.也就是一般的关联 
来表示纽合与聚合. 


设计原则 



I 1 ?!: 但是.假如不知道哪 一种类 

型的关联应该被用 a. 开发者不会感 
到很困 惑吗？ 

^: 坏是可能的.但它也尤许史 

多的灵活性，01设你稍后决定 S 军团 
( army ) 被榷 》时，你不想让单独的 
战+单位 ( unit ) 也被摧 ft . 因此你可 
能想让军团 与戍斗 单位的关系从 te 合 
t 为聚合. 

低如你使用基本的关头.你定全 
不需*改变类田.它給予开发者自 
由.让他们对于如何实现此关*找出 
&己的 想法。 

使用 ftl 合或《合的符号时没有什么对 
与错，不应该太 执着. 特則是 S 你在 
开犮的早期阶段.你绝对不会知道稍 
后会有什么改变，而灵活总比值化对 
系统更好。 
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我是谁 _? 


骑骑热喪够？ 



我让其他人帮我做事. 


oo 原刖所涉及的一群类全都盛装参加一场化妆舞会，玩着-猜 
捎我的游戏 • 它们会给你线索并且总是说真话，而 你试着 
猜出它们是谁。假如它们*巧说出对一个以上为真的线索，就将 
所柯适用该叙述的答案挑出。在句子旁边的空白处 填人所 有适用 
的答*。 

今晚 来宾： 

子类 被委托类 被聚合类 

( subclass ) (delegated class ) (aggregated class ) 

委托类 组合类 

(delegating class ) (composite class ) < 译注 7> 


我的行为被用作另一个类的行 
为的一部分。 


我改 变另一 个类的行为. 


我不改变另一个类的行为。 


我能将其他几个类的行为结合起 
来。 


即使其他相关的类消失，我也 
不会消失。 


我从我的基类型获得行为与功能 
性。 


► 鋒注 7: 即为 'composingclass" . - ► 答索见第 420 克。 
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设计原则 


要点 




通过让类允许为扩展而开放，禁止为 修改而 
关闭，开闭原則 （OCP) 让你的软件可重用 
且具有灵活性。 

通过单一职责原則 (SRP) 让类做单一之 
事，甚至让运用 OCP 到你的程序代码中变得 
更简单《 

当你在试着决定某一个方法是否为某•个类 
的责任时，问问你自己，做此特定之寧垃此 
类的 ft 任吗？如果不是的话，就将此方法移 
角其他类 

当你几乎完成 O0 程序代码时，务必确认不自 
我* 复。避免* 复程序代码，确保程序代码 
中的毎一个行为只出现在单一地方 • 

DRY 同时适用于需求以及你的程序代码：你 
应该让软件中的每一项功能和需求在单一地 
方被实現。 


假如你发现程序代码违反 LSP, 考虑利用委 
托、组合或聚合来使用来自其他类的行为而 
无需诉诸继承。 

假如你需要来自其他类的行为，但不需改变 
或嫌改该行为，你可以简单地委托该类去使 
用想要的行为。 

组合让你从一整群行为中选择行为，常常是 
通过接口的一 •些实现. 

当你使用组合，组合对 ft (composing 
object ) 拥有 ( own) 它所使用的行为，若组 
合对象停止存在，这些行为也会停止存在《 
聚合 Lb 你使用来自其他类的行为，但没有限 
制这些行为的生命周期。 

即使在聚合对象 (aggregating object ) 被摧毁 
之后，被聚合的行为仍继续 存在。 


■ 通过要求子类型能替换其基类型， Liskov 替 
换原則确保你正确地使用继承。 
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OOA & D 工具箱 


工兵箱 


V 我们乂多 r 很多 oow_sr 以加入此 u: 我们将所7: 
r 的东西加人我们的 ^ld。Id 住：这些 W 則 》4f "fe 被运 ffl, 而 
不是分开I 


一衫條 L 

妗的索 求 * i . 一-一~ - - -- 聆听 審户，找出他 f } 屬伢 构遠何 

托期邱样注说科农 好的炊 件容異汝変岛$么》 

硌认你的翥值用{■象刼装岛鏈承 ci 样的籑肩用審户理解的诘言绍合功秸列表。 
㈣ 用例。00_来祕你的炊件这:"1功拥4審声在立想#/ 


ii 用 p 00涿則 

你的搴。 ' ■ 

_用< »*«^***- 
.屬的#!的姓 o 鏃砝，布不4的隹现。 

进你 的〗在用《埤的》-个遣 P •有一个** 蚨変。 
饬的 t ! 类*荚子 竹妁島 功铤伐的。 

( A 威长类应该元许为护暴*孖汝.禁 《1 为硤汝 
* 关闭 （0 CP ) 。 

—(|过将共阉2物柚蚁出乘斿 * 子辈一地 
方來逡免 f 4的《存代铥 （0 RY 琢削 ） 。 
系统1的备一个的象部左 1 •在只有 年—把 
t . 辦奄的象的服务部在技鬱详在实现 

itv.fi 5i (SW) • 

孑类蜇必领拥眵《搞《 签类智 （ LSP) 。 


功拥*審户在 is 龙的 

® (以及用例） 6_ Jjf . 系 

►解咸 许多较0.的 部分。 
I 式注用 f _) 簟统中较 .). 

OOA & D ^ 則巧莕 一个 
设丹#1埤 3 



设计原则 


4 ^ OOyl&D 瑱字游戏 

这一个是特别复杂的宇 a: 几乎所有 的答案 都超过一个单 
词。祝你好运， il: 你的左 B 动起来吧！ 



1 compositi 
one object 


横排提示 

I. A variation on corr 

3. This is when or 
other objects. 

6. This is when you hand over responsibiJity for 
a particular behavior. 

7. He was all about substitution 

8. The LSP reveals problems related to this. 

II. You should keep a single piece of code in 
this many places. 

13. You should have each piece of your 
information and this in a single, sensible place. 

14. _out things that are common in 

your code. 

15. Each object in your system should have this 
many responsibilities. 

16. This is overrated in good OO software 
design. 

17. Another term for SRP is this. 


竖排提示 

2. Aggregated objects exist_of the 

classes that use them. 

4. Subtypes must be substitutable for these. 

5. Classes should be closed for this. 

9. OO principles work best when used this way. 

10. A well-designed class has only one reason to 
do this. 

12. Classes should be open for this. 
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oo 原刖所涉及的-辟类全都盛装签加-场化妆舞会.玩若 •■猜 
猜我 &谁” 的游戏。它们会给你线 索并且 总是说真话，而你 W 着 
猜出它们 是推- 假如它们*巧说出对•个以上为离的线索.躭将 
所有适用该叙述的答案挑出。在句子旁边的空白处填入所 飪适用 
的答案I 




子类 被委托类 被聚合类 

(subclass) (delegated class) (aggregated class) 

委托类 组合类 


1 我可以替换我的基类里 
1 我让其他人帮我做事。 


(delegating class) 


(composite class) 
子类 


我的行为被用作另一个类的行为的一 
部分。 


破餐合类 


_ 这 4 签本的 
* 托宜 A . 
<8 值用含威 
的 ft 也 4 的 
•j « )6 * 值 
用 » 他 t 


我改变另一个类的行为。 




我不改 变另一 个类的 行为。 


我能将其他几个类的行为结合起 
来。 

即使其他相关的类消失，我也不 
会消失。 

我从我的基类型获得行为与功能 
性。 


破洼托类 . itHta — 子*4»9-含 

组合类. 凌托类 


歧轚 合类.歧洼 fet 




合 fei 托 
中的象求制彼 
辨宅 ft — J£ («j 

象⑽ ft 斿不 A 
*t 体麯 .. 



设计原则 


习超 


解答 




少年亊件薄 

——移辟谀计饰乏涓宍的务穸斛著 


Joel 的大错误在这一行被 发现： 

他甚至将类型为 Weapon 的特性添加到他的 Building 类中，因此 
在追逐牛群的漫长一天结束后，牛仔们可以将装备挂起来。 

当 Joel 决定牛仔们可以将武器挂起来时，他承诺让 Lasso、 
Revolver, Brandinglron 类存在干单独的 Unit 实例之外，没有牛 
仔拥有 (own) 该装备，他们 只是… 度使用 (use) 该装备的行 
为. 

W 为 Weapon 实现存 在子特 定牛仔之外， Joel 应该使用聚合代枰 
组合.不间的牛仔在不同时 间"] ■以使用 M -个 Weapon 实现，而 
这呰武器应该持续存在，即使使用它的牛仔被•只狂牛抬踩扁 
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9 迭代乌测试 



是让客户知道你真的很在乎他的时候了。唠叨的 老板？ 忧心的 

客户？相关人员.天到晚在问“会准时完成吗？”设计良好的程序不 
足以取悦你的 客户， 你必须 ii: 他们看见某些真正在运作的东西。既然 
你已经有了坚实稳固的 oo 编程工具组，现在正是学习如何向客户证明 
你的软件确实可行的时候。在本家电.我们学>1到两种深入软件功能 
的方法，在客户的心坎上 带来股暧流， it 他 们说： “婊的，你确实 
蛙担任这项工作的最佳人选I ” 


了不起的开发者 


你的工爯箱満？ 

到目前为止，我们已经学到很多东西，分析与设计工具箱也 
相3满了.我们甚至在上一章还加了一些 oo 编程 技术： 





/. 确认你的取件 
秒著户要它秒的 

亊 .， 



2.运用基本的00 


^屏 JW 来埤加轸件的 


的三唼琢 4 现在 
» I e . <s 我们在 

* 个*争 i «- 
6«用。 


•? •努力实琪可雄 
铲，可*用的 
珙计. 
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迭代与 



然而你还是在 
为窖户编 写软件 r 

你所学到的工具和技术都很榇……不过那 
些都跟你是否使用它们编写让客户离兴的 
伟大软件无关。 

大多数时候.客户不地在乎你所创建的 
oo 原则或围形.他们只想要软件做它该 
做的事„ 
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是 送代进行的。 


Joe ： 足啊.也 iY •我 们不该将所有的时间花在那么多 的围形 
及架构相关的事情上 • 除了一 6¥椭圆形，里面写着“创达棋 
盘”之类的字眼外，我们没什么东西可以拿给 Gary 看。 
Frank : 喂，开心点，兄弟，我们有的东西可不只那些。现 
在，要完成 Board 类会很简单，因为我们已经为此功能准备 
了不少 材料。 

Jill : 嗯，当然。不过，那是我们已经编码的唯一类，堆道只 
拿那个给 Gary 看吗？ 

Joe ： Rg .. 我想我们还可以较 a 地骂好 Unil 类，因为我们已 
经为它做 4 f f 类图。 所以完成这个类不会花多少时间. 
Frank : £确！我们确实知道如何写好所有这些类.我们可 
以拿毎一个* 甚至螫 个包，并且将 所科的 oo W 則以及分析 
与设计技术应用到毎一个功能块 （chunk of functionality ) 上， 
Jill ： 但是我们现在就必须实现功能，没有时间再做.准整体 
轮麻 （ bigpichire ) 的分析与设计。 


拂作，孥着铯代 
应 用移疼 的每个 
片揆， 篆 E 。 


Frank : 不过， jm , 那就是重点所在，我们不需要改变我们 
正在做的事，只要迭代 (iterate) 得更深入一些， 

Joe ： 迭代得更深人一些？什么意思？ 

Frank : 意思是我们继续进行分析与设计，但现在要特别针 
对 Gary 的游戏系统框架的毎一个单独的部件 （ part ) 。 

Jill ： 然后， 随苕 应用程序被构建，我们会有更多的有效片段 
可以给 Gary 看，对吗？ 

Joe : 然后我们就能够使用所有已经学到的工具来确保软件 
是设计 R 好的，对吗？ 

Frank ： 正确.但首先,我们有个选择要作…… 



迭代与测试 


更深入地 迭代： 
两种塋本选择 


谈到开发软件时，存一种以上的方法去迭代 W 人应用程 
序的特定部件 （pari) »你必须处理较小的功能性片段 
(piece of functionality) ,但是有两种基本方式决定要操 
作哪些小片段——甚至所谓的“小片段”对应用程序的意 
么是什么。 

你可以选择聚焦在应用程序 的特定功能 (feature) 上。 
此方式完全关系到取出客户想^ 功能性 片段.并 
且实现该功能性，直到它完成。 



功能驱动开发 

(Feature Driven Development) 

挑出应用程序的特定功能，并 R 规划. 
分析及开发该功能， A 到完成， 


两种送代 
(iterating ) 

方式皆由 | 

(requirement) 
所骓动。 


你也可以选择聚焦在通过应用程序的 特定流程 (flow) 
上。此方式取出通过应用程序的 完整 有清楚 
的开始与 结束) ,并且在你的程序代码中实现该^ 
(path) „ 



用例驱动开发 

(Use Case Driven Development) 

挑出通过用例的场景 （scenario) , 
并且编写程序代码以支持通过该用例 

的完整场彔。 


因为脔求湛令著 
户， 两种方式 勒 
: 聚诔在矣付者 
户要的方西上 r 



• H id 


用. 
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功能驱动孖芨 

在使用功能驱动开发时，一次做单一功能 
( feature ) ,接着迭代，一次解决一个功能， （ S 到 
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迭代与测试 
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两种孖芨方式 

只有一种*本的方式来编 '1J 程序代码吗？不，事实上有许多 
不同方式迭代深人，完成应用程序的各个部件.然而这苎方 
式大多数 r 我 们在屙 的这两种堪本分类，因此如何决定 
用哪一种？ 

在功能埏动孖《乌用例駔动孖龙之闲布 什么不 
©? 


功能萑动孖 龙比较 
细粒化 ( granular ) 


輩一劝《枝往 
<5的6用《* 

-sdtt I" 





当你有许多未密切相关的不同功能时. 
工作会进行得比较好。 


用例駔动孖龙比餃 
整体化” （big picture ) 



几犬块《 序代 
«. 因# 輩一 


当你的应用程序有许多流程与场最. 
而不是个别的功能性片段时.进行得 
比较好。 


让你可以较快向客户展示可运作的程序 让你在每个开发阶段可以向客户展示 

代码。 较大的功能性 片段。 


是非常功能性驱动 （functionality- 
driven) 的。 采用此方式，你不会忘记 
任何功能。 


是非常以用户为中心 (user-centric) 
的。 采用此方式，你将为用户使用此 
系统的所有方式编写程序代码。 


对具有许多未连接功能性片段的系统. 对交易式系统（系统以 冗长. 复杂的 

进行得特别好。 流程定义而 成）. 进行得特别好。 





♦我选我选我选选选 


W 系 1 


欢迎来到“我选我选我选选选！”节目，呪甩.这个历宙啦！ F 面垃一些 iff 
句.毎-个邯愚关干迭代系统部件的-种特定方式,你的任务是找出该语句 
弓哪-种方式 有关， 注息啦，有时候一条语句可能适用 T •两种 方式，不一定 
是个萝卜一个坑”喔！ 

用例枢动 功 能祖动 


此方 式一次 处理应用程序的一个功能小 
片段。 


aT 


此方式让你一次只聚焦于应用程序的一 
个部分. 






此方式完全关系到应用程序中的完整流 
程。 




□ 


使用此方式.你总是可以测 试一下 ，看 
看你是否己经完成正在操作的应用程序 
的一个部分。 


使用这个方式时，你的焦点是在一个图 
形上.而不是在列表上。 




□ 
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迭代与测试 


让我们采用功能驱动孖茗 

因为 Gary 失去耐心，让我们采用功能驱动开发吧，我们 "f 以取出单一功 
能，将它完成，它不 会花费 像编码以支抟整个用例那么多的时间. 

毎当你的客户急着要看结果时，你应该考虑采用功能驱动开发，从-个 
你已经完成一些工作的功能开始。 




frary 的游戏系统梅楽 
功能列表 

1 . rt 相* i 辩不尚*型的《形。 

2. rt 枢* 支辩不网时代，包宮 a 杓的 
时代. 如科 幻的成的。 

/-lit « * « 

' V 寒 型的部 趴乌 战斗单 flu _ __ 

4.* t 相*支辩 用子额外的故 》« a 斗 
坫景的外接損坫。 

s 此相楽熳供由方袼组成的祺盘.毎 
-个 方格邾 》«地®*型。 

6. 杜梅荣進踪轮到谁缲作。 

Z*t 相*协 « s 础的 桴动。 


么就让我们妗此 炎鍵® 技璆 
代 tS . ftfl 把功抽 《3生 
致。 




type: String 
properties: Map 
setType(Slring) 
getType(): String 
setProperly(String, Object) 
getProperty(Slring): Object 


戧们也知迮 丈砟分 fl 链功 赵保 
枝此走.这让戧 (HS 奇 * 由从 
6 鬌孚。 


罅 — 

假如你决定走用例驱动开发的路，你会先从哪 fR 




分析你的功能 


功能分析 


-- •旦决定要从哪个功能开始，你必须再多做一些分析. 

让我们从功能列表上所写的东西 开始： 

f 此柜楽格埯遨戏的不阁，支特多种类型 
的部队乌遨戏特定的战斗单位。 

我们也有来自第7章的 类图： 


' re —这*我们 os « 揭有的…… 
iia * 兵子我 ( Hi 蝤 
«的攀的相的紐 


type: String 
properties: Map 


setType(String) 

|getType(): String 

roperty(String, Object) 
IgelProperty(String): Object 



® . 郎 4 <5 科 么糸® 边漼 对 


我们似乎已经具备1•要开始编 Pi 所擗的-切，对吗？为 
了帑忙确认没存遗漏任何事，咱们回过头再使用一些文 
本分析 （textual analysis) 。 

我们不必分析整个用例，但我们可以再一次看看 Gary 
的电子游戏的远景陈述，看看我们是否涵盖了 Gary 要 
战4单位做的每一件事。 

这4第 6 耷中的达— ■* 
*»tio 


将 Unit 的类图与远景陈述作比较，类图漏掉 
什么东西了吗？ 

当你说“我已经为框架里的战斗单位完成编 
码”时，预计 Gary 可能会看到什么其他东西 
吗？ 
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鐮 Gary 的电子游戏 _ 

远最陈述 

的* 供.个磬《 系 ttKM io«»s_ 

Fruncmrt, OSF) . Ill 以倒 ItH 合 M 策 《«« (BIUI . 不 Hf»* 中心! 

»* (« cfc -.. y | c , tao , 以及依的电子 游戏， R ,, 
的 MteiM 放战水的 tt 术 tMM (■+• ariKKCMMKtn . 
«»定*»!的 #*«»» 黎.复性编 《1 工作的 ft> 负相. 
此游 《 系统植 》)() 餮个 ill 子游* asm 供-个梭心.它#以矣程痄摩的杉式时 
tt 并 ftft —组*义 ft 好的 API, 供4>司内 郎所* 供 s 游戏 (bowlgxoe) IKttil 
的 ffSJiaa 队使用. 此框贱 供的》准功*有： 
h 衣本供盘 fidS (board coofiguratioiO 


«队及配置’ 
S (board) 


[军团 或者其 tt«4« 位 （u 


• W 定 ft 法的移动 
• 暹行《4 

♦ «供》斗*位的《患 

故<^特_化《命»«(略» <1 的开发I.作. m 變 OSF 
的《«*—-1以将 MWAW 在*«真*的游 ttrtttk. 








迭代与剷试 


将 Unit * 付诸®观 

在类图中，我们已经想到的 -W 是如何表示战斗单位的特性 

(properties ). 然而在 Gary 的远 R 陈述里，他«期游戏系统抿 这 ®v«*(n<S *7#ft 

架会: fc 持的 东西 远超过那些游戏特定的特性 - 个 U«+ t * . 

茶 •=! 4Um'< 的溥* jj 鞾定的鞾乜 

这里是我 (H 想到的 Gary 预期框架电的战斗单位会做 的事： 


❶ 

o 



Vr ° 


每个战斗单位应该有特性 (properties). 而游 戏设/ _我们的 ft® OS »« 子 

计者可以增加新特性到他们自己的游戏中的战斗单位 
(unit) 类型中。 


战斗单位必须能从棋盘 (board) 上的一个方格 
(tile) 移动到另一个方格。 

战斗单位能被归组在 一起形 成军团 （army) 。 


« 一一榷昶戧 们(5華7辈婷扣 荚荚铒 
功的 irt . 的子如向公 
Sii - 点. Cf •在, .s 含有一眘 
Sit, 


« 4 6戏以 
Qaiy 栌 ijS ». 




展示 Unit 类 

我们之 iii (完成 f 对游戏特定战斗单位的支持以及如 H 
存储 Unit 的特性 （第 7 帝）， 但要想说服 Gary 相诂 
你正在 8»处《毎一件私，只有类阁足不够的。 
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编写测试场景 


_试案例 (test case) 不必非常复杂,它们只是提供 
个方式，向客户展示类里的功能性正常运作， 


.*t " ib f 

fi 在谈的用例法* ( 

scenario) # 7•和 ffl 。 


对 T •战斗单位的特性 (properties) 来说.我们可以从 
创让新 Onit 件增加特性给该战斗单位的简电测试场 S 
(test scenario) 开始。我们可以向客户展示运行中的程 





















轵渰著户 


嫌攀 [ Unit 的组 















迭代与测试 


情节*5: 获 取一个 不存在 的特性 值 


对十 3 T •:个场我们决定测试：与你试 111 获取_-个从末_被设定过 

的特 性讷 时会发生什么唞？像这样的错《会+时发生 . 我 们可不 ii 个 诉審户 你不 

想毎次游戏设 If # 打错卞成在程序代码中犯一点错， aih 我们的 jj . JS / i . 也常 馑用? 6 

程序崩 m ， 这里 &为测 试这种状况我们所做 的亊： ® c ： 外的代况. 



你应该为 斯有 侪雔&到的 可熊的值芹 状况 
濟试侪的 要有 fe 象 i 

也刿忘3羽试轸件 > JE 确谀芹的状况。你 


将在早期桷扠位铐誤, it 你的者户 莴兴。 












% 

Ip ) :我们还没编写程序代码， 
现在就担心瀏试.是不是有点本末 
倒置？ 

^: 一点也不。事实上 ，饥如 

你在編码之前就知道即将使用什么 
測试.要想 出什么《序代码可以通 
过那*測试就会很容易。有了我们 
刚則开发的三个測试场景，要编写 
Unit 类应 a 是相当«单的，而 i 測 
试会告诉我们《序代码的行为到底 
该如何. 

1^1 : 这不就是测试驱动开发 
吗？ 

V :大体而言是的.正式地 
说.測试《动开发把焦点放在&动 
化《试上. 通常牵 涉到诹 JUnil 之 
类的《试柜架 • 然而，编写測试業 
W , 接屬編写会通过测试的《序代 
码. 这徉的想法才是測试驱动开发 
背后的核心 板念。 

1^) :那么.我们是在使用测试 
驱动开发还是功能驱动开发？我被 
弄糊涂了。 


选出小功16来实现 （功能 ffi 动开 
发> • 最后你 T 蚝运用測试想出如 
何实现该功能 （测试 《动开犮> , 

1^) : «试为何如此简单？我原 
本以为会有炫 一点的 东西。 

^ : 要保持你的測试«单. 
让它们一次只 *1 试一个小功能性片 
段。慨如你开始一次測试 多件事 
情. 就很*分辫是什么摩因造成特 
定的 错误. 你可 能需* 更多的測 
试.仨保抻蚤一个都聚焦在非常特 
定的功能性片段上. 

1°) : 毎个* 试都*保类中的单 

一方法运作正磽.对吗？ 

^ : 不.每个測试实际上聚 
焦于单一功詭性片段.这可能涉及 
一个方法或一* 方法. 例如.你不 
能单单只*试设定特性值（使用 
setProperty (>) -而不设定获取 
特性值（使用 getPropertyO ) 。 
因此， 它是一个功 tt 性片投——设 
定特性，扭使用7«种方法. 


1^) : 能解释一下你为什么瀏 
试■•对没有设定的特性取值 -? 这 
是不是在瀏试 Unit 类的错误使用方 

式？ 

^: 通常.測试软件的不正 

确使用至少跟測试正确使用一样重 
要。游戏设计者可 徒很容 ft 就拼 
错特性的名称，或者《期游 呔的另 
—个片段会设定菜个特性.而編写 
的《序代鴿请 求实标 上不存在的特 
性。知道在这种状况下会发生什么 
事•正是你的工作. 

I ®): 既然己经准 备好* 试.我 
们躭终于可以开始编写 Unit 类了. 
对吗？ 

^:呢.还有一 痊设计 上的事 
要先想想。 


^ :两者都有„事实上，大 
多 致良好 的软件分析与设计*合了 
许多不 n 方式 • 你 t 能从用例开始 
(用例《动开 *> . 接着在用例中 


羽试骓 动扞赛棼诔子让 
实•的行为芷确„ 
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Joe ： 什么意思？我们想到 Unit 里的所有特性都有名与 值。 因此， 
我们决定使用 Map 将它们全部存储起来。 

Frank : 游戏设计者通过创建新的特性名称来添加他们想要的特性， 
并利用 setPropertyO 方法将名/值对放在 Map 里。 

Jill : 是的，然后我们也增加 type 特性，因为所有战斗单位都有类？！ 
(type) 。那是所有战斗单位共有的•…” 

Joe ： 没错.你看，我们确实做过共同性分析。 

Jill ： ……然而我们现在也知道战斗单位能被归组，像军团或规队 
等。耶么假如我们在 N —组里有两个相同类型的战斗单位.会发屮 
什么亊？ 我们如 何分辨 

Frank ： 你&在想我们是否館耍某种 id, 不赴？ 

Jill : &的. UiM ••吧，或者窀少是个名字。但即使那样，你不能真的 
防 ll: name 特性的重 g ,是吧？ 


type: String 
properties: Map 
setType(Slring) 
getType(): String 
setProperlyfSIring, Object) 
gelPropertytString): Object 



这 4 Ftanfc. mH to* Ofift 
讨论的 Unit 


Joe : 是的，但那并不表示我们需要改变设 ih 我们以只给名为 
properties 的 Map 增加 1D 特性。那样，我们就会有一个很好的一致的 
方式，使用 getPropertyO 方法来访问所有特性， 

Frank : 川 I ，我想他是对的。因为我们把特性名称的细节封装到 
名为 properties 的 Map 里，我们甚至可以从使用 ID 改成使用名称或 
者某种完全不同的东西，而使用 Unit 类的程序代码也不必改变那么 
多……只需要在 gctPropertyO 里使用新的特性名称。那可是相3巧妙 
的设计！ 

Jill : 饥足 JtM 性如何呢？假如 ID 对干所冇战斗单位来说真的都是共 
同的.堆进不应该从 Map 屮被移出来，像我们利用 lype 特性所做的 
亊職 

Joe : 咔……封装或共 同性。 真难……好*无法*顯, 







再探共同性 


重新 精炼獅 共同性分析。 _ 

' 在我们合上书本，幵始处理 Unh 的特性之前，还有一桉事你必须想 淸馅. 下面是不 

|»1 战斗单位可能会舟的_•些特性及两张纸。将你认为所奵战斗艰位（+莳任 
fJ) 邯会打的特性写在•典1«1性， （commonalily) 那张纸 .h, 将你认为只有特定 
类型的战斗单位才町能有的特性写在••变化性” (variability) 那张纸上。 

战斗簟 tt 的 漤在特性 

name (€均> weapon (武 S> allegiance (忠瀘度 ） gear (装杳> 
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观点问题 


Unit 的组 




你的铝笔 

^ 重 新精炼你的共同性分析。 


在我们合上 1S 本，开始处理 Unit 的特性之前，还有一些事你必须想请楚.下面& 
不间战斗单位可能会有的一哼特性及两张纸。将你认为所有战斗单位（不管任何 
类窀）都会有的特性写在••共 同性- (commonality) 那张纸上，将你认为 R 有特 
定类型的战斗单位才可能有的特性写在•变化性” (variability) 那张 纸上. 
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你可能对什么造就好游戏有不同看法。 

你玩过的游戏"『能跟我们玩过的不•样， 
► 并 .n. 想到-•些不同的共同特性，那例也无 


妨. R 要聚热于你如何以及为什么作出那样的决策就可 
以了.我们将在本孝其余部分使用我们的选择，你应该 
对我们的决策放心。 








迭代与测试 


我 ff ) 旖 Oft 的鹑乜邾 
样中 . ® 
妗它 <H 部 只4用在轉 4 



吗？ 

: 你一点也没错.分枒与设计 

都关系釗作选择.有时候.你的选择 
会与其他 tt 夺设计《不 《. 这无关对 
错，只要你对所作的决策有良好的. 
深 . S 熟*的理由即可. 


答 


是的. S 然会。然而 
OOA & D 及軟件开发与设计无关乎产 
生特定的决策.因为很多时候并没有 
完 •全••正碥" 或艽全•不正嫡-的选 
择 . 它 *1 关系《編写设计良好的杖 
件，而这可由许多方式实现. 


全不《的设计决策.让我们 ft 设一祌 
状况： 两个《寺设计对这里的共同 
性与*化性都想《相(*1 的答* ,然后 
试着更新 Unit 类以反映他们所想到的 




解法 #1: 聚焦于共同性 


解法 *1: 
强调兴罔性 



在此解法中，所有的游戏设计者能 K 接访问 id. nam •与 

weapons 特件. 而不必使川 getPropertyO 从 U 通用的 
properties Map 取值。 

这31强调将 Onit 的共 M 特性保存在 prop.rti.» Map Z 
外.并 R 将变化的特件钳作 prop.rti.s M« P 之内. 
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设 i 十决策总是一种取佘 ( tradeoff ) 

Sam 选择强调跨战斗单位共同的亊，但他的决策也有 -- 
些负面的 效应： 




我们正在自我重复 

现在有两种不同方式访问特 性：通 
alg«tld(). getNameO 苫特定 f 特 
性的方法，以及通过 getProperty(> 


方法。 两种 i 方问特性的方式肯定会有某作重复 
的程序代码。 



* 你赛存代砝奄重 
4的；«在芍.你运 
4金找 K 通扣*更违 
«Wii« 



维护是个问题 
现在你将 id 与 nam« 之类的 
特性名称写死 (hard-coded) 1 
在 OniC 类中。假如游戏设计 
者不想 要使用 那咚或者想要改 
变它们， 8P 将会是个麻烦并且澥要改变 Unit*« 
这通常坫封装能俄 b 忙的地方，而这也将我们 
引导到后面的 Randy 的设计选择上…… 





此解法聚焦于将 Dnit 的所有特性封装到 properties Map , 并且 

提供标准接口- getPropartyO 方法， 以访 问所有特性.并至连 

适用干所有战斗单位的特性， ( fttyp .' aid , 也是通过 pr 0 p « r ti «« 
Map 被访问《 

这 Ml 强调的取点坫封装及 炅活的设计 。叩使共同特性的名称改变， 
Unit 类也 蛘以保持 W 为没有特性名称被写死在此类中 . 
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运行时的诸多工作 Q 

getPropertyO 返 Object , 而你必须 
为毎一个特性值将 Object 转甩 (cast) 

成正确的类®,这些全都在运行时发 
生*那可是--堆的转型工作，是程序代 
码在运行时要做的一堆额外工作，即使 
对所有战斗单位类型共同的特性也是。 

夺醵 - 

你认为哪个开发莕的解法最好？有没有什么时候 a 你认 
为 k 个解法是嬝好的选择，而丼他时候 是另一 个解法 -T 
能运作得更好？ 
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你 必须作 出扶择 

让我们采取认兵间性 
为恁点的解法 

对 rGary 的游戏系统抿架，我们采取 Sam 的解法.它将战斗 
单位共同的特性取出放进它们自己的特性与方法中.并将 
战斗电位特定的特性留在单■独的 Map 里。 


lyim^Unit 的移动 Unit 的组 



鞾定 H [溥 找典 
4的鞾 ft 卽赶 <5 
*k Map f 


_ Unit 

type: String 
id: int 

name: String 
weapons: Weapon [*] 
properties: Map 
setType(String) 
getTypej): String 
getld(): int 
setName(String) 
getName(): String 
addWeapon(Weapon) 
getWeapons(): Weapon H 
setProperty(String, Object) 
getProperty(String): Object 



迭代与澜试 


% 

1^) : 我认为另一个设计，*焦于封装 的那一 个比较 
好.可以 BJ ? 

: 1 ^ : S 然 T 以.两钟设计选择都有其优点. 

任何一个郝可以.唯一 不允许 的穸情，是 S 它 
运作不 tt 时你不愿意改变你的设计 （无 论你从 
哪一个开 始）。 在开发应用《序的每一个迭代 
(iteralion) 阶段， 你必須 重新评《你的设计，确认它们 
是®固竖实的。 

:那我怎么知道何时该改变我的设计？我的程序 
代码不会只是停止运作，我该留意什么_? 

^ : 迭代 (iteration) 真的是这里的关鍵，许多设 
计决策在开发中的莱个阶段看起来很好，但随着你深入 
&用《净的莱个特定部分，它会出现一姿问 a 此. 
一 s •你作 T 决策. 就要; If# 它并见 在乃一个迭代蚧段中 
史深入你的 应用; 《序，只要你的设计在运作并 A 运用良 
好的00摩則及设计樸式，你的工作就是順利地在进行. 
然而，彀如你开始遇到决策上的困睢， 邺么别 害怕改 
变. 让事情重新运作起来。 

1^) :当我无法在一些好的设计选择中作决定时会发 
生什么事？ 

答: 你总得作决定 • 即使你不是百分之百确定嘩一个正 
确 .， 尽量去猜并看看事■情如何运作总是比较好的，而 
不是花费无敫的时间去争论，这叫分析癉痪 (analysis 
paralysis) ,而它絶不是一个让事情完成的 做法. 即使 
你不定全磯定正螭的答案*什么，就从其中_条路径开 
始.也达比什么决*都不作要好. 


g •妗的轵件长逯过 
绝代缠駄芮成 .. 节 
祈、珙计， 再―爽 

成应用核序其 止真 
•的部尹。 

每当 你铯代 时，！ 
新评信 你的设计決 
%,傚扣它对你的 
设计令球，馱别害 
怕玖实。 
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比对你的测试 鸟设计 

我们 £1 经有了要，给 Gary 肴的测试场》 , 以及对 Onit 类的 
设 I 十，编码之前要做的圾后 .• 件事，坫确认我们对 Dnit 的 
设 U • 会 It 我们编码出通 过所有 测试的程序代码 . 


方法句 让我 们宄 
«抓中的件攀 


name: Siring 
weapons: Weapon [*] 
properties: Map 
setType(String) 
getType()： String 
getld(): int 
setName(String) 
getName(): String 
addWeapon(Weapon) 
getWeapons(): Weapon [.1 
setProperty(String, Object) 
getPropefty(String): Object 


用 ■”《» UiiitO • * 


UnitTaster 
ng the Unit class... 
..Created a new unit 
•. Set type to ''infantry" 
..Set hitPoints to 25 





type: "infantry" 
hitfoints: 25 


f|. gbtfi 用 《tPu>p*tt»0 岛 • 


OnitTester 
,i.ng the Unit class. 
•Created a new unit 
•Set hitPoints to 25 
.Set hitPoii 
.Getting unit 


:s to 1! 
t hitPo: 


村此*试來 ft. 洩们不 t*<il 
ftlPtepnt) ( "ttMnfth " 〉料看着 
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编写 Unit 类 

已经《«两荥/ •. 终屮准备 好要为 Unit 类编写程 序代码 
了，我们是这么 做的： 

package headfirst.gsf.unic ； 


public class Unit { 
private String type; 
private int id; 
private String name; 
private List weapons; 
private Map properties; 

« - 

public Unit(int id)) 
this.id = id; 


我们 aa 构淺*數 R 


public int getldO 
return id; 


. 我们 Sf 龙 


^ 4 («1. 我们谷 此不射 
-出这螫葡♦的 方法。 







测试案例检査 



测试案例蘚析 


关于测试案例我们已经谈了很多.但到目前为止，你还没看到 
如何真正编写一个测试案例。让我们仔细 査看一 下测试案例， 
看看到底是什么组成了一个好的测试。 


O 每个测试案例应该有 ID 与名称。 4/ 

澜试案例的名称应该描述什么事情 正要被 测试，只在尾端标上数字 
的测试名称不像 tes tProper ty < ) 或 testCreation 0这种名称那样 


尽 * 7 鬌以 

' Us,r ♦命名*试.尽 


有帮助。你也应该使用数值的 ID , 因此你可以轻易列出你的测试 
案例（我们在下一页会做的 事）， 

O 每个测试案例应该有-件特定的事要测试。 : -个. 

W - 茶个甚 g 多个类 …… frc. 

毎个测试案例应该是原子性的 （atomic) :飪个测试案 话.靶 .《 点爸乜 携菊章 

例应该•次 q 测试一个功能性片段。这让你完全 M 开可 性圬 《I_.- 次 -个。 " 

能无 aSi? 程序里运作的功能性片段. 


Q 每个测试案例应该有你提供的输入。 汗 .15.. «4 

你会给测试案例--个值或 -- •组值，作为澜试案例要用的 
測 U ： 数据，这个数据通常被用来执行某个特定的功能性 
片段或行为。 

O ^^ C $ S *«/ j £ s . a , 

每个测试案例应该有你预期的输出。 夂〜— ®, ^ 

-- , A 

给定输入之后，程序、类或方法应该输出什么？你将比 ::二 (梦兵）. 

较实际的输出与预期的输出，假如相符， 测试便 成功. 

软件能 运作。 


o 


大部分的测试案例具有起始状态。 



你黹要开启数据庳连接，或创达某个对 fe , 成在 测试运 
行前设定某些他吗？假如需要的话，这《?全都垃測试案 
例起始状态的-■部分，擗要在实除的测试运行前被处 
理. 


时 umttJMd. -a c « ^ is 
媾杖 S, 我们 * 
*rWUnii*w. (S4E 不多杖 
4(i 鞾。 
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4尖你的铝 f 

^ 设计你的测试案例。 


下面垃 W： 冇5列的衣格，坫列表氺测 W 案例的5个 《要部分之你的 
任务垃利用我们已经在本联说明过的用例 UX 1 来填苟此衣格。我们已经 
先完成茁•行 来悄你 起个失， 请将 Jt 余测 W 案例的空「1填上。 
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测试很要紧 


unit 的组 


设计你的测试案例。 

^^ 下面是有5列的表格.毎列表 示澜甙 案例的5个®要部分之 一i 

你的任务是利用我们已经在本章所说明过的用例倍患来填写此表格。 



<5 . 我 tns 

入和用. 


JO 

测 该忖么 

铪入 

殒期輪出 

起始杖态 

( 

« w 的轉《 

~ intanti^" 

"type". 

intanttj/ 

现有 Unit 约象 

2 

m/Hn 

« 斗 #(2» 史的 »« 

~hitFoints" • 
25 

~hit?oints" • 
25 

现有 Unit 对象 

3 

珀 《 现 

"Ai {Points" 

15 

"hitPoints" 

15 

现有 U»il 的象 . fi liuPomK 

AiSLAii 

4 



"stienfth", 
； 4«« 

现 时拿 . t) Itittiftk 


妗坤 伐拢供 (6, »«试 


S 


> f 问句 


匈題 


l ° i : 我们的3个》试场景怎么会变成4个瀏试案例？ 

^ : 因为*一个測试场景实际上測试两件 事：设 

定与取得共同 的特性（有它 6己的变量与访问方法. 
像 g _ tTyp «(>> . 以及设定与取得战+单位种定（或 
游味 特定） 的祌性（通过 9_ tProp * rty <) 被访问.像 
hitPoints ). 郅是内个不《的功能性片段，因此需要两 
种不用的測试*例。 


I ®):所有这些测试案例会让我们知道我们的软件正像 
它应该做的那样运作，对吗？ 

^ : 是的.这是个好开始. （* 是*记住，我们开始 
縞写 》1试. 以便向客户证明我们_直在編写的 *t 件真的能 
运作 • 我 们的測 试案例让客户看到一#«序代码真的在运 
行，并且#我们在开犮用期 （dcvelopmenlcycle) 的较早价 
段中找到《序代碼的 缺陷， 





迭代与测试 


羽试拼窗 

既然你已经知道测试案例并 a 已经写在前面的衣格1,说明你已经准备 4f 编 
写测试类 (test class) 来向客户 it 示你的软件能运作，并向自己证明你所写 
的程序代码没有缺陷。 

问题： 

Gary 想要知道游戏系统框架里的战斗单■位支持工作的进展，你 
想要确认你为 Onit.java 所编写的程序代码运作正常。 

任务： 

O 创建名为 DnitT«»t*r.java 的新类，导人 (import) Unit 与其他有关 
类。 

O 为你在第456页的表格中所想到的毎个测试案例增加 -- 个新方法。务 
必为毎个测试方法 （te« method) 使用具有描述性的名称， 

O 虹个测 W 方法应该接受完成起始状态设定的 unit 实例，以及任何其 
他运行 测试 1 i 比较输入和 W 期输出值所擗的畚数。 

O 测试 方法应该在 oniti 设定提供的特性名称与特性值，接矜使 用悚期 
的输出特性名称来获取预期的 輪出特 性值。 

O 假如提供的 输人与 预期的输出值相符，该方法应该输出 'Test Passed' 
(测试成 功）， 若不相符，该方法应试输出 “Test Failed” （测试失 
畋） 并伴随着不相符的值。 

O 编写方法，为毎个测试方法设定起始状态，然后运行毎个测试。 

红利 积分： 

O 在 anit.j*v* 里有一些东西没被第456页中的场扶测试到，将它们找 
出来并且为它们分別创途测试方法。 

O 从你的 a«inO 方法运行这呰测试， 
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羽试拼固斛考 




S 个 M 试方法 
«有7•甬誊 
&. © J 6 S 个 
方沾部&在》 
试 Unit 龜中 
不《栌寧， 


public void testType(Onit unit. String type. String expectedOutputType) { 

’ System.out.println(''\nTesting setting/getting the type property."); 

unit • setType (type); 

String outputType - unit.getTypeO; - - ^ j U 杉 * 

* if 一 ctedoutputxyp,.—•(outputTyp^TP 

System.out •println(''Test passed"); S? ^ * ra- w S ss * ： 

个 1 else { 

jj System.out.println("Test failed: " + outputType + '' didn't match ~ + 

' expectedOutputType); 

^ 1 〜陶她 — 

> 0 巧粉入耷發出岱。 

.public void testUnitSpecificProperty(Unit unit. String propertyName, J 
Object inputValue, expectedOutputValue) ( 

System.out.printXn( w \nTesting setting/getting a unit-specific property. w ); 
unit.setProperty(propertyName, inputValue); 

Object outputValue - unit.getProperty(pcopertyName); 
if (expectedOutputValue.equals(outputValue)) { 

System.out.println("Test passed"); 

I else { 


expecteauutputvaiue)； u »i ii . . „ _ , 

, « M 试几吁咢 ® 子 t«lUmtS|ieci<icPiop«ty(). 

} 只老奋 起始伏 S3 衽光 《 <i 鹑作设金成另 4 

^ - -的 

► public void testChangePropertydtoit unit. String propertyName, 

Object inputValue, Object expectedOutputValue)( 

Sys tem. out. print In ( M \nTesting changing an existing property’s value. w ); 
unit.setProperty (propertyName, inputValue); 

Object outputValue = unit.getProperCy(propertyName); 
if (expectedOutputValue.equals(outputValue))( 

System.out.println(''Test passed"); 
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鼉后这个 》) 试不**鑰入值. 
因;6这 就** 刑试的*由： t 
托先 设金的麵性， 


public void testNonExistentProperty(Unit unit. String propertyName)( 
System.out.println("\nTesting getting a non-existent property’s value.~); 
Object outputValue - unit.getProperty(propertyName); 
if (outputValue -» null)( 

System.ouc.print 1 n("Test passed ”； 

)else { 

System.out.println("Test failed with value of " + outputValue); 


public static void main (String args[]) 



AitPointS'(Sl<stUnitSpeci<ic( , ti>p»ty() 
IAHA 25 . 因 rt 我们刁以碣用 
t* 9 tC(iaiij«P* 0 |i«t»(). fcilit 耗伐 Cfi 4 
S 含在此 « 试中*曾 iiL 


y", "infantry"); 

,tSp«cificProp«rty(unit, 'hitPointa", 

n«w Intagar(25) I naw Int«gar( 
(unit, > 'hitPoint«", 
new Integer(15), naw Int«g«r(15)); 

tester.testNonExistentProperty(unit, "strength"); 


现在，看看红利积分…… 

我们在表中增加3个测试案例来处理所有战斗单位共间的3个《 
性，它们没有在 UnitTester 中被测试到.你应该可以根据此表格 
编写额外的测 W 方法。自己想出这里的答案了吗？ 


会 S# 试典 ft。 


}1他3个 ftR 鹑1 . 
@ 的 8 —个郐沒 " 
用它<3 6的鎢龛 、 
这闲*法。 


JD 

删试 ft 么 

餘入 

拽期餘出 


( 



"intanti}/" 

«$(!■“_ 攀 

2 

斗 * fi» 定的》 

ti 

~hitPoints". 
25 

"hitPoints" 

25 


3 

挺 «««»««(* 

~hitPoints" 

15 

''hitPoints" 

15 

现有 Unit 的攀 . ft fcitPointf 
* ； iS25 

4 

»« 不 » 焱 * 

i 

~SlllKfth" 

成尹 UnifS^ 象 . ;4 f c r t r M $ f h 

5 

unu/m 

ib 

(000 

现时象 . W 僅妗 1000 

6 


'- ZL - 

"Damon" 

现荀象 

T1 

嫌知 / 取得 WMP0KS 

Am 的象 

A « 时象 

珑有 Unit 时拿 
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向窖户 ii 硪 

有了 Unit 类及-•组澜试案例，你已经准备好向 Gary 展 
示一些可运行的程序代码，证明你正以他想要的方式构 
达游戏系统框架， U : 我们运行测试类给他旮： 



a ……#试美不》太 
乜感或 太今人 兴旮. 

玥你的故辞破 
它这漱的攀 w 芍： 



Testing setting/getting the type property. 
Test passed 

Testing setting/getting a unit-specific 
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让我们为游戏系统改变 编程契约 
(programming contract) 

当你编写软件时，你也在 建立软 件与其用户之 
间的契约.此契约详述当某个行动被采取时， 
如请求-个不存在于战斗单位里的特性，软件 
如何运作《 

如果客户想要*个行动导致不同的行为，那么 
你躭耍改变该契约 • 因此.假如不存在的特性 
被谢求时 Gary 的框架要抛出一个异常，那也 
很好，那只是表示在游戏设计者 与框架 之间的 
契约已经改变。 


当你按努约鑛程 (program by 



coni rad ) 资若 餐件的芹户 

芷同意该轸件％待定方式行动 r 



S 知金的 I 多秦义 



契约式编程 


到 © 前为止，我们一疽在 
桉契约编程 

你町能没有注意到，其实到卩前为止，我们 •(！ 在 Unit 
类屮 做一件•叫做■•契约式编程" （program by comracd 的 
事。 ftonit 类中，假如*人谪求•个不存在的特性，我们 
就会返问 null, 我们 ftg«tw« apons uitU 故冏样的亊.假如 
n«apons 列丧未被初始化，我们也返冋 null： 



戧们现的碘*含扔喊 
Umt 

功 tt 作的 I ! _•)•«!； 



印 fi < s 不知逢. 

<54义《灼.灼 
t * ?»<1 T (S <1 
0•(食 ft 4 f + 么辜 


达是 Unit 的契约 

Onit 类假设使用它的人是能干的程序设计师，他们能 
处理返回值为 null 的情况，因此我们的契约陈述着像这 
样 的事： 


嘿， 你看起来相当聪明，假如你请求不存在 
的特性或武器，你能处理 null®. OK? 



翁约 …… * 


►译注I:当 Map 不&含此嫂或者此嫂真的对应到 
null 值时.其 gelO 方法返田 null. 
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契约式编程兵乎信任 

当你返回 mil 附，你倌任程序设计师能处理 nu || 返 M 值. 
某本上，程序设计师会说他们已经把程序编与•得相当好， 
不会去清求不存在的特性或武器，因此他们的程序代码 
不用担心会从 Unit 类取回 null 值： 


嘿.你看起来相当 聪明。 假如你请求+存在 
的特性或武器，我将返回 null, 你能处理 null 
值， OK? 


听#,我们知道我们在做什么，我们的程序代 
码只会向你请求存在的特性 • 所以，就返冋 null 
吧…… 相信我 们会做 iE 确的事， 0K? 


我们总是能改变淡 


f 要的活， 

契约…… 

回到第461 我们被要求停止返回 null, 而是以抛 
出异常代替。这实际上不进一个契约上的大改变， 

只是表示如果游戏设计者请求不存在的特性或武器 
将会有大问题。 

V你知道吗？我们真的很有信心，不会向^请求不存 
在的 特性。 事实上，假如我们这么做的话，就抛出异 
常吧， Ik 程序停止运作.而且我们会把缺陷给找出 
来.相信我，抛出异常吧.没问 S 的. 

当然，只*你知道我会开始抛出 Exception, 那躭没 H«。 

我会改变我的 程序 代码.开始使用这个新 K 约吧. 






但是，假如你不信任你的用户 



可能送给你们 null, ifii 你们可能崩渍。所以，为1•安全起见， 
我会送给你们一个 Checked Exception, 你必须捕获它以确保 
你不会拿到一个 null 值并用它做什么*事。 




试《侈衫 OS (* Cf .) ^ 
闲成狨的鯈枕。 


► i>ii2： Java 主♦提供两钟异常 (Exception) : Runtime Exception 
以及 Checked Exception. 所有的 Checked Exception 都是从 
java.Iang.Exceplion 典衍生出来的•而 Runlime Exception 
*'| 是从 java.Iang.RuntimcExccpHon 或 java.Iang.Error 典衍 
生出来的.定义方法时必《声明彳《会樾出的 Checked 
Exception. 而调用此方法时必《掮获玄的 Checked 
Exception ,不然就是要把该 Checked Exception 传遂 下去， 
反花 Runtime Exception 的情形， H 不必声明，也不必搞 
获. 


464 第9簟 





迭代与测试 


或者假如他们不信任你 


* i 然， 程序 设计师在用你的程序代码时，他们也 " f 能不信 
任你……他们也能做防御性编栉。万一他们不相信你只会 
从 g * tPir O p « irt y 0 返问非 null 值呢？干是他们会保护他们的 
程序代码，并且使用防御性 编程： 


这&值用的枝 
烊代 il 坫例。 




% 


1®) : 你在第463页说我们可以改变契约成抛出异常. 
但是在这里你又说抛出异常是一种防御性编程.我被弄糊 
涂了. 

^: 哪一种异常被抛出真的不是那么玄要 . 4•要的 

是你的*户与用户如何被幸涉到该决 策中。在契 约式編《 
中，你与用户对你们如何处理问《取得共识‘；在防# Mi 编 
«中.你的决策乃奠墓于螭保不论用户要做什么，你的<1 
年却不会《清. 


的意見（第461页）并1同意以特定动作作为请求不存在特 
性的 " ft 应来做到。稍后，我们会使用 RuntimeException 
异常，那是因为客户不想在他们的《序代码中增加太 
多 try/c*tch 块。当然，他们也 T 以只是角单地请求 

Checked Exception. 而我们也可以同意-还是契约 

式編 《. 

相较于契约式 «tt, 在仿 御性鴆《里. 我们对 客户想 ♦的 
东西就不是郎么有兴赴。在此，我们确保我们不会让<1序 
«清.甚至埤 界去帮 助客户免于让 他们的 《序《清 • 


S 我们决定从返田 null 变成抛出异常时，我们通过聆听 S 户 






真 心话： 保护程序设计师 

® 炉在话 


今晚 主题： 契约式编程与防御性编程 
程序设计师倍 任议题 (trust issue) 大论战 


契约式编程 防御性编程 

很髙兴來到这申.跟你面对面，我们真的没什么机会像 
这样坐在一起。 

是啊，我真的不太喜欢出门，毕毚好多事情都会 
出错。 

你的意思是…… 


嗯，我可能在过马路时踩到没被垃圾收集器检 
走的 Banana.peelO (香 蕉皮) 而滑一跤,或者有 
些没有良好终止条件的循坏在十字路[I呼啸而 
过……有很多坏程序代码在那里，你知道吗？ 

呃.当然.我想足的……但你不能.辈 .f. 部活在坏程 
汴代码 的阴影卜\在某些时候，你就足必须衣态你将 
如 H 做.并 H 怙任程序设 计师会 讯确地使用你 • 

你在开玩笑吧？你遇过的大部分程序设计师所 
W 的程序真的谈得上 ••倌 任”这两个字吗？他 
们忙若看 《Lost» ,根本没时间检丧软件里的缺 
陷。 假如他们停止边盯着电视边写程序，或许 
我就不必对他们的工作做那么多遍复核 （double- 

乖乖，听起来你好像有信任上的问题。 

你没有吗？ 


是的，我没有，我信任程序设计师了解我提供给他们 
的契约. 


契约？脚，你还认为假如你解释过在某种情况下 
你会怎么做，“好”的程汴设计师就会正确地使 
用你吗？老弟，你太天真了！ 





契约式编程 


防御性编程 


迭代与测试 


听 fi ,我的契约沾楚地陈述我必须做的事以及使用我 
的人必湞做的'取， 

你没听过叫？有50%以上 的娇约 （coniract) 
(译注3> 都以*婚收场……或许那是》外一回亊, 
我不太确定……不管怎么样，你真的认为程序设 
计师会注怠你的小小契约吗？ 

假如程设设II•师和用户不遵守协议的话，我可以不必 
为此 负贵。 若违反契约，他们自然会付出代价，我可 
没有义务保障他们的婚姻幸福 美满。 

听起来蛮无 情的。 我试着帮助我的用户，甚至保 
护他们防范他们自己的错误。 

使用一大堆额外的程序代码（像 *if(value == null)") 

到处检査？这太煞风景了，而11好像会把毎一件事怙 

都拖慢. 

当然， 柯时候 虽然牺 牲一苎 性能. m 我确实 it 毎 
个人邯平平安安，免遭灾难。我常常把我 Gd 想 
成…… m . ……奵点像超人。 

超人？不会吧…… 

是真的！此外，.有多少次你的程序代码陷入一团 
m . 只因为一个懒惰的程序设计师忽略你的契约。 

但那就是重点！我可能对懒情的程序设计师不算很好， 

但对确实检査他们X作的程序设计师而言，我可是非 
常之好！当他们使用我时，他们获得的性能更佳，程 
序代码 更短。 

程序代码更短，哼，我宁可有好程序代码，让程 
序设计师与用户平平安安的程序代码* 

那正是我提供的，只是没有信任的问埋以及你身上那 
-- 堆包袱，还有你那自以为有的红色披风…… 

°R. 现在我眼你就有倍任的问《…… 

我会11：你肴肴什么叫安全的程序代码，你这个小 . ►译注 3: coniracl. «约.亦作 ». 


•信 号中断…救人喔 - 
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猜猜我 g 指 •. 


骑骑我喪 够？ 

0 ^ 


功能驱动开发.用例驱动 开发. 契约式编程以及防御性编程令部 

现身在.场化妆舞会，当中没有人社名聛，令都聚在.起 
你来听听他们 | K 在聊什么，试笤想出面具后的人垃谁，小心，有 
时候会有一位以上的来宾说出同样 的亊。 


% 我是非常井然有序的人，軎欢一步一步处 

m 理事情 • 直到我从头到尾地完成。 


嗯. 当然. 她说她会调用的，但你如何能 
够真的再相倍任何人？ 


没错.需求给我动力。 

我*行为良好的人。事实上.在进行其他 
事情 之前. 我一直把焦点放在自己的行为 


真的，这完全关系到我的客户。说穿了， 
我就是想要满足他们。 


嘿-你是个大人了，你能自己处理…那真 
的不再是我的问 H 了，对吧？ 

只要你好好与它共处，我也会。只要你知 
道你能从我这里得到什么.我就无需告知 
你该做什么。 
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迭代与测试 


4尖你的铝 f 

又为 Unit 改变编程契约。 

Gary 的客户想要 Unit 假设他们会正确地使 用它。 这表示如果不存在 
的特性被请求，就表示游戏里有某件事真的已经出错，异常必须被 
抛出。你的任 务是： 

I . £新 Unit . java , 让请求不存在的特性导致异常被抛出。由你想出 
要使用什么类型的异常。 

2 •更新 UnitTester.java 以及此契约改变会影响到的测试案例以反映 
出新樊约， 

3_ ffi 新运行 UniiTester , 拥认 Unii.java 还是通过所有的测 



If 下 
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g 你采取 契约式編稃 时,你 JE 在鸟窖户的程序代码 
含作，认对你将如何处理布问超的状况 达成协议 。 

g 你采取 防砷性編稃 时.你正在碥保窖户荻得“安 
全的”响应，不管窖户要什么。 


的鹑 <4的 伏况。 



I®) :你说契约式编程导致较少的程序代码.但我们 w I®) :我还是不明白我们在此为什么要转换 a 契约式编 
才好像加了不少程序代码到 Unitjava。 程.它为什么比较好？ 


^那是因为代鸶直接返 ® null , 我们樾出新的 
RuntimeException. 然而那是特例，不是经常的，大多 
数时候.你在趿务》鴒 (service side) 不会有很多 頦外的 
代珥，因为你只是单炖地返田值与对象.没有頦>|•的 
检金未看它们是不是 null 或是在*个彀据范围内. 


: 它与较好或较坏无关.而是踉》户要什么有关. 
事实上.你很少（I已决定要用《约式編《还*彷獅性編 
«. 昂 真的* 由本 ■户要什么以及将使用你所編写的软忤的 
家户类《来决定. 






战斗单位的移动 

移动战斗单位 


花■时用 : j •我们 
-个劝««««7 


(unit) 类型中。 


我们终 T •完成战斗单位的特性，可以前进到下一个 
项目了： 

^ 毎个战斗单位应该有特性 (properties). 而游戏设 
计者可以增加新特性到他们自己的游戏的战斗单位 



成 ft . 

4UI 移 it 


战斗单位必须能从棋盘 (board) 上的一 个方格 (tile) 
移动到 另一个 方格。 


O 战斗单位能被组在 一起形 成军团 （armyl 。 


我们认前没来过迖里码？ 


这听起来相 -1 熟悉，我们在第7章已 羟处 理过移 
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将你的应用程序分解成 
较小的功能块 

我们已经谈了许多关于迭代深人应用程序的寧，在毎一个 
阶段做£多的分析与设计. W 此你分解毎一个问 B (不是 
分解成用例.就垃分解成功 能）， 然后解决叫《的_ •个部 
分，一次又一次.这是本章我们一直在做 的亊： 取出电 - 
功能，实现该功能， K 到完成《 


然35你还玎认将搴锖迸一步分蘚 …… 

然而一旦你选 取了单 -功能 （feature) 或用例 (use 
case) ,你通常可以将该功能分解成甚至更小的行为 
(behavior) 片段。例如，战斗单位有特性，以及我们必須 
处理战斗单位的移动，另外，我们也需要支持战斗单位的 
归组.闪此甸•个单独的行为片段必须被处理. 

就* 当你分解应用程; T •并开始迭代时，在毎一个少*中.. 
你必須做《£多分析.总足要确认稍孕的决策合理，如采不 
合理，就改 变或® 做。 


ii f 的问《 4 



我们连择_场功鉢 



你的决策也能迭代进行.越采越深入 

多数时候，你会发 现稍羊 所作的决策彻底地节省了你的工 
作 时间。 在 Gary 的系统里，我们决定游戏设计者要自己处 
理移动，那么既然我们正在谈如何处理战斗单位的移动， 
就可以采取我们稍早所作的决策并将它应用在这里。因为 
它似乎仍然合理——没有什么理由改变此决策，我们可以 
让游戏设计者去拫心战斗单位移动的处理，然后进行下- 
个行为片段。 


兵子本问 ifcWrt 的決 


* 他 ( Dt) ㈣ 4 



Q QQ 




0^ 战斗单位必须能从棋盘 (board) 上的一个方格 
(tile) 移动到另一个方格。 


' 戧* 以在 Um ' tS 中的这_个行 
巧上打勾。 


Q Q 9Q 






战斗单位归组就翥你了 


到现在为止，你应 该对功 能驵动开发.迭代，分析，设计都釘 


相当多的认知了，我们将把#11、•的工作留 给你： 处 fflJftlTf …个 
行为 片段， 完成 Gary 的游戏系统抿架的 unit 功能， 


»:*i T it iHW . 


问题： 

Gary 的框架需要支持战斗单位的归组。 

任务： 

o 创建能将战斗单位归组在.起的新类，并且能在组里增加及移除战斗 
单位。 

o 将要用来测 试软汁 •的测试案例场景填 A_F 面的表格。 

O 为 UnitTMtM 增加方法来实现下表甩的测试场最，确认所冇的澜 试都 
成功。 


广 

•a <5 tt 4 Ci 
使用 M <5 的* 
格行 ……成老 
P . «值用 ii 螫 
袭縳 矜。 

L 


JD 

刑试 fU 

鑰入 

孖期餘出 

起诒较态 
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要点 




■ 编好软件的第-步垃确保你的应 
用程序像客户预期的或想要的那样运 
作. 

■ 客户通常不在乎图表与列表，他们想 
要看你的软件实际在做的亊情。 

■ 用例驱动开发•次把焦点放在应用程 
序用例中的一个场欤上。 

■ 在用例职动开发中，你一次把热点放 
在申..场铁上，然而在移至共他坩例 
中的从:他场 a 之前，你通常为中 -* 
例中的所冇场 k 编码。 

■ 功能驱动开发让你在进行任 m 其他事 
情之前为完整的功能编码。 

■ 在功能驱动开发中，你所完成的功能 
可大可小，只要你-次处理一个功能 
即可。 

■ 软件开发总是迭代的，你舂见整体轮 
廓. 接着迭代深人较小的功能性片 
段。 

■ 在开发周期的毎_•个阶段，你必须进 
行分析与设计，包括当你开始完成新 
功能或用例时。 


■ 测试让你确保软件没有缺陷，让你向 
客户证明软件能运作。 

■ 好的测试案例只测试一个特定功能性 
片段。 

■ 测试 案例可能只牵涉到单-类中的-- 
个或一些方法，或者牵涉到多个类， 

■ 测试驱动开发的基本想 法是： 先编写 
你的 测试， 再开发你的软件，通过那 
咋渊 W, 坫采坫 功能完 *!. 冇效运作 
的软件， 

■ K 约式编杩假设协议双方了解什么动 
作会产生什么行为并 EL 遵守该契约„ 

■ 当错误发生在契约式编程的环境时， 
方法通常会返回 null 或未检査异常 
(unchecked exception) 。 

■ 防御性编程寻找会出错的亊，广泛地 
测 K 以避免出错的状况。 

■ 在防御性编程的环境里，方法通常会 
返回 “空” (empty) 对象或者抛出已 
检査异常 (checked exception). 



宪成 Unit 类 


功熊拼窗解考 


Unit 的组 


Gary 的框架楢®支持战斗单位的旳组，并且也应该允 
许这些组归组（游戏设计者可以进行嵌套的归组 （译注 
5)). 


叫的 « (**»). 
jeis/.u”u ?) 象本 
ifjmptfy(t (»*〖《) 。 


CS：(ii3f4 入-个敁斗 ^ 括的 
的 UmtQwuPo 

public UnitGcoup(List unitList)( 
units = new HashMapO; 

for (Iterator i = unitList.iterator(); i.hasNextO; ) { 

Unit unit = (Unit)i.nextO; 的 ,a 

units.put(unit.getld(), unit); ^ 构这将斯奇钱斗 # fS 坩*>到名巧 

) “” 心的 M 印 f, «5 个里典 场 （„ ) 

• 的霣设砝战 4#(g 的 jc^ 


public UnitGroupO 1 


this (new LinkedListO); 


public void addUr>it(Unit unit) { 
units.put(unit.getld(), unic); 


iia 使角钱 4 荦 (3 的 
M*P. «f)«k/.JDft 


ii4 个猓 耔的功 


inits.get(id); 


public List getUnits() { 

List unitList = new LinkedListO; 



►译注 5: 但 目莳的 程序代码未处理这个部分. 

有兴趣的读者可参考《深入浅出设 
计模式》 •£ 的 "Composite Paltern" , 
那是=1■能的好解法之一， 


for (Iterator i = units.entrySet().iterator(); i.hasNexCO;)( 
Unit unit - (Unit)i.nextO; 


unitList.add(unit); 


return unitLisC; 


斗 * 仿存甸印 f. Tonnuuf, 
t'i 战 4 輩 (SfcOO* 存噼含 f 砑 . 
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扣认 10 孖谂. 免携岛现 
<；的》试#例*淹《 


)0 

刑试矸么 

餘入 

领期餘出 

起始杖态 

10 

由 a 斗辈佬列表 
&) 逮射的 UnitQsoup 

战斗辈倍 
列表 

和阌的 a 斗 
荦话列表 

沒有现有的 
UnitQtoup 卖例 

(( 

坩加 a 斗荦伝 i _) 

闼 i 

JOft^lOO 
的 a 斗#佳 

joa^ioott 
a 斗#佬 

沒有數搞场的 
UnitQtoup 

12 

以: > Dga 佴战 斗辈沄 

(00 

JD 值碎100的 
战斗輩 (S 

沒有&匆场的 
UnitQioup \ 

(3 

KflMSf 的 

M <5 战斗#沄 

h 

苻 合初始 列表的 
4*4# 倍10表 

S <53知战斗輩佳 
列表的 UnitQtoup 

14 

W.li4 *fi6f)^o 
移铨战4荤沄 

100 

战4#沄列* (沒 <；jd 
岱的（00的战斗荦佳） 

•:4<5 教昶珀的 
UnitQtoup ^ 

15 

以 a 斗辈话的龙 》_j 
移餘 a 斗辈沄 

30(0^)100 
的 a 斗辈倍 

战斗荦 ( S 列表 0：i^30 
氓巧 〖 00 的战 4荦话） 

UnitCJitoup 、 


Ci 签* 裁们 S f •) 的 
Unit(itoup-Ji^.§«j . 
饬 SWUfS 的5喝， 


裁 们喜欢从交的 UxitQwp 
iH &. 以碥 侈我们 鰣存的战 
斗#倍在钱斗 辈括列表中斿 
不存窃。 




你应该能 利用上 述表格甩的 * 试案 例编写 UnitTester 。 假如你想要 
比较一下我们的程序代码 . 览 hKp://www.headfirstlabs.com ， 点 
击 “Head First OOA&D* , 寻找 "UniiGroup Test Cases ” 。 
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00 A 邛 X 爯箱 

我们已经学到了一些开发方式来迭代深入你的项 h , 甚至 
有本®中 两个抒 通的编程实践.把这咋令邯加人你的工具 


鍔的* JMS 13 ----1聆畤窖，.我出的 fDJ 饬构4付么。 

邦样注 fV : 设錡电好的饮 4容易故変耷护果。用審户*铒的谘言绍合功鈦列表、 
5|认伤的髴4访田值祕轚岛齷采这样的馨本郎碥认仿的功戧4莕户 4 iS # 的房 

00康則 |# tt 。 3 


将窆化 之»«««来。 

的戏 C3S (砝.布7 •蕞对 索现。 

在用《璆的* 一个 类只布一个《由《64。 

走4 荚子行 >6岛功 tt 性的。 

( ocp ) 读 f 主头线 

襄约 式编裎 妁伢鸟软件用户同 
系统中金 遵夺的&件行 為瀘在一个共 
* 的巧罔的访议。 

； (SRP) 御性 SM 呈 ; T ■信任苒 他欽件 • 

子进矜广泛^传茯5•數孩桧杳以 
磘侈苒他故4不含狳饬方在的 
或不 S 全的作总。 


秕 aii 它注用用例田 （ wa 用咧）釗遠系蜣的 

*<$te 麄®. 

13 •* * ^* 八办 ■*»••« « ，‘一 .、 

幵 发方式 

在进朽左用《[序的《何真 
估專之前光 fei 蕈统的輩 一用例 .稃£ 
_强4实现螯个用 例的杈 4 代砧上 .色 
含它新有的场 f 。 

矽翁期功孖盔 存进行左用沒序的《何真 
估 寧之前 光鈀该点放存荦一功翁上. 4 
11巧该功餘的辦有行巧鹐砝。 

巧功抽铽爵光巧功 
钝性圬段 譌写 测试访 f ,戏«铽 写飲件 
以 a a 蚵有淛 该。 

在好 ft _的幵 盔涵常 在幵发屌期 的不同 
阶段.辖含所有这曲孖盎 拽彻. 


迭代与测试 



CXVI&D 填字游珙 

本章有 I 午多新名 UO, W 此这 M 的填字游戏有许多东两要 
填。复习 -F 本联内容，符你是否真的都理解！ 



横排提示 

3. Never be afraid to da this in design. 

4. This type of programming protects you and 
focuses on preventing errors and invalid dot。. 

6. You should test your software for this kind 

11- Iterating your development based on 
specific pieces of functionality. 

12. Feature driven development is very 


15. Good development is driven by these. 

16. Customers just want their software to do 
this. 

17. Developing your software based on 
scenarios through a system. 

18. Getting stuck trying to decide on one 
design decision or another. 


竖排提示 

1. This is what you use to prove to the 
customer that your software works. 

2 - Program this way when you trust your users, 
and they trust you. 

5. Testing weird and strange usages of your 
code will Kelp you catch errors_. 

7. Use case diagrams and feature lists don't 

make sense to the__ 

8. Design decisions are always a__ 

9. A single test case can focus on this many 
pieces of functionality. 

10. Great software is written like this. 

13. You write software for the_ 

14 Once you choose a feature or use case, you 
need to do this again. 
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骑骑软喪 够？ 


i 


功能明动开发.用例 ffi 动开发.契约式«程以及防御性*程令邡 

现 »在-场化妆轉会.当中 没有人 ft 名 W. 令郁《在一起騄天 • 
你来听听他们正在麟什么. «S 想出® 具 K 的人进 *• 小心，有 
时候会有一位以上的来宾说出间样的事， 


我是非常并然有序的人.軎 欢一步一步处 
理事情.直到我从头到尾地完成， 


«. 当然.她说她会调用的.但你如何能 
«B 的再相倍任何人？ 


没 《. * 求给我 动力. 


我*行为8好的人.事实上.在进行其他事 
情之前. 我一直 把焦点放在自己的行为上。 


防御性级我 

功能驱动孖龙 f 约 

用例驱 动孖龙 

衫式. 


功能驱动孖龙 


真的.这完全关系到我的客户。说穿了. 
我就*想栗满足他们. 

嘿.你是个大人 T. 你能自己处理 那真 
的不再是我的问囲了.对吧？ 


全部 f ^-~~~ 这喳技木 

—* - SIS * 的® 

荚系《铪菩户 
他们* 的 ft 件。 

契约式 編稃 


只*你好好与它共处.我也会.只要你知 
道你*从我这里得到什么，我就无*吿知 
你该做什么. 


契约式锒稃 
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组合在一起 


准备好 了吗？我们 -a 作运用各种方法来改務你的软 
件， ifri 现在该足时候把 -Wj 组合起 来了。 这躭1你•在在等 
待的事情，我们即将运用你-»在学习的毎-件亊，并且让 

你孖到这些真的全邯垃伟大软件编 W 流程的•邢分- 

次又.次地编勾出伟大软件。 



孖芨软件， OOA ^ 风格 

到 B 前为 ll :. 对于 如何开 发伟大软件，你巳经拥舟 忤多新 
的 Hft . 技术与想法……但我们还没有其的将它们全部组 
合在一起. 


那躭是 本章的 内容: 将所有你知道如何做的单独之事，如 
找出需求.写下用例与运用设计模式，转变 成可® 复利用 
的流程，一次又一次地解决最难的软件问题。 



砾尚对象分析设 H 


确弘侪的轵件你著户要它炒的事„ 



j W 4© 

巧 坩如不濞逢伐 的效件 ft 免 C 
* . 你 tt 不 JJ 块劝， 




OOA&D 生命周期 




送代扞矣 




弗烤加炅沄惟。 





3. 


努力宍现可维铲， 
重用的珙计„ 


可 




让我们使用这个流程，从头到尾 
构建软件项目。 

我们已经使用过这个流裎的各个部分来 
完成穿本书的各个软件項 p. m 还没 
有真的将它们组合起来，然而这-切 
即将改变……本拿将 u； 你构途一个相当 
复杂的软件片段，从功能列表 （feature 
list) 到实现与 交付。 

一路上，你会看到你一直在学的所有东 
西会如何帮助你构建伟大软件。准备 
好，这将是你最后的 W 炼。 



OOA&D 生命周期 



ooyi&om^ 


注意：此习超的答案不会出现在下-页 作答后 mum 
读本章.在本章结尾处，我们会回来看页鬌这 m 咖 


在我们深入本窜即将要解决的 NS 之前，你必须真正知道你一直在学习的所有东西符 
合整体 OOA&D 项目的生命周期。在本页底部有一些你已经学到的 OOA&D 磁铁，你 
的任务是试着把它们放到 OOA&D 项目生命周期（如下 所示） 的正确阶段 （phase) • 
在毎个阶段你能放罝一个以上的磁铁，而有些磁铁你可能想要使用一次以上。杩慢 
来，祝你好运。 


井 foe a 多* 求所段 
5 鼉个 起 




你 ㈣ f •侦个 




问超描逑 

这1.足我们在本茯即将要进 行的项 H ,从头到堪 


1对象村旅游有《公和 

I 畤象«<1*■路210今 


工作说明 ^ 

恭喜！ 基于你在 “Rick 的乐器行”与“超棒狗门”项目中的优异 
表现，我们想要委托你负责全新的对象村旅游路线搜索器。 

由干近来到对象村的观光人次递增，我们想要提供一个方式， 
it 游客更容易了解对象村独特、美妙的观光资源。路线搜索器 
(RouteFinder) 应该能够存储对象村完整的地铁麵网络，以及 
毎条地铁线路 （line) 上所有站点 （ slation) 的信息。对象村的 
地铁系统㈣先进的系统，能在各站点之间来回运行，因此你 
完全不 用担心任何- .条地铁线路的行车 方向。 

路线搜索器应赚接受起点站与终点站，并且找出旅游路线 
(roule ) 0 旅行社规能输離路线，指明薇 乘哪些 地铁线路， 
会经过哪觸点，及__■柳酿 贼卜 一条 
线路。 

我们为对象村的灵活性与可扩展性深感骄傲，所以企盼路线搜 
索器也能容易扩展，因为我们所想到的新方式是要让游客享受 
到以对象为基础的最佳旅游经历。 

漏很快麟娜的刖 ■ 与有麵作娜綱雜。全靠你广！ 
顺祝商褀！ y f 

Orbin Traveloctic, 苗席执行官 

附言： 为了 _你 开始，我们提供对象村的地铁线路图，以及 
内含所有站点与地铁 线路 
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本否4故意留仓的 . a 楫你 
杖芍以 筠下 下一页 I :既酷义 
炫的时象村地®. 4将它贴 
佬的睬 斬 I :。 


e 工《二_ 


下一8的地铁 B 上的地铁线路 (line) 是以 OO 領域的先《与大师来命 
名的. Boocli. Rumbaugh 与 Jacobson 三人是面句对象方法论的三巨头 a 
Gamma A {Design Paltcrns》 一舡的四人 ta 作: if 之首. McyerJt OO 技术 
S 典之作 (Objcci-Oricnlcd Soflware Cons(ruclion) _•(* 的作者. Wirfs- 
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本 II 教逢 t 杳 ( i 釋该 
#雩鉍*下1-?5矚螓 Att 
齡对 攀村嫱鬌，4 籌由 tt 存 
i 傕的 《_ i . 





我们把亊情交拾你，你的 fE 务坫利用第488 豇 的工作说明开发出功 
能列衣。假如你黹耍帮忙，51以畚考第6饫。功能列表 ff 起来躭像 
r® 这样： 


OOA&D 生命周期 



的位 B 
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铪 i 4 ■-个辈吆 的 1 * 

ft 

功*表 ft 食它。 


、党问 和匈翅 

1^1 : 我们为什么不收集需求？我还是不太明白* I®) : 你为什么将输出路线视为单独的功能？ 一 
求与功能的真正差别。 旦有了两个站点之间的有效 路线. 那只是相当简单的 

^ 事. 不是吗？ 

: 需求与功能常被互换使用^然而大部分时 

候. S 人们在 边应用 《序需要做的大_情时.他们会 ^ : 可能是.然而功能列表不只是你必《解决的 
说■•功能 _ . 因此要滿足一項功能可能需要几个* *題列表.而是你的应用 任序必 《能够做的所有亨情 
求.因为功能通常是大一点的整体轮*.从《肖功能的列表. 因此. 即使功能看起来 《j 单且微小.也要把 
列表开始新喟 h * 个好主意.就诹我 们对路 》■搜索 a 它放在你的功能列表中。 

所做的亨一蛘. 













OOA&D 生命周期 


现在你应泫炙的知道 
该傲什么了 


此刻，你已经完成I•第一个阶段, 



准备好功能列表后，你对应用程序该做什么应该 
有很好的理解了，甚至可以开始想应用程序的结 
构，尽管稍后我们将 花费电 多的时间在那上面。 


一 H 确认7■你的功能列表，你应该继续前迸到用 
例图 (use case diagram) ,它们会帮你从应用程 
序做什么接连到它如何被使用-—那是客户真 
正感兴趣 的事， 


ta ••的 功鶬刊彔 舜纟兴系到球斛你的取件 js 该 
| 什么。 

用例 g 让你犴炜 思考你 的取件将扣何衹儇用 , 
—拆 yr •霖赛 >—摊 yr •必要的钿节。 






OOA&D ^ 
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习8« 答 



裤荅 


决定路线搜索器的程序代码结构.并且将用例对应回功能 
列表。 

你杏"削尖你的铅笔” ~ -功能磁铁-要解决.你应该想 W 系统 
的参与 者与 用例，然后确认这些用例涵追1 •路 线搜索器必须 i；W 
的所有 功能。 


此劝《的此死剖的注 
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用例反硪 使用性 ( usage ) , 

功能反硪 功能性 ( functionality ) 

lh 我们！ tff 细地«所示的“功能一用例■•的 
比对结采之 



事实上，用例••栽人地铁线路网络”并未直接使 
用“表示地铁线路及沿线站点”功能，但是很明 
显，我 <n 必须表示地铁线路以让此用例能运作》不 
过，要将这两#像这样绑在_ _•起的话还需要一点延 


伸工作， 

然而那不是•个错误。在编写用例时，就是在处押 
参与者与系统之间的交互 (interaction) ,就是在谈 
系统被使 HI 的方式（这躭垃“用例” .WI 的由 来）. 




用的方式 .. 


I 衣示地铁线路及沿线站点。 





系统里的功能 （feature) 反映系统的功能性 


用例 条托功 钺3(?以注作， 

芍枝 不&用例本矣的郝分歩癉 '戤 入** 
枝线珞闲结—体杨_.表矛油技线珞总沿铐 
a 6 .- an . fssi ® 戏值用砝 劝裢. 


(functionality) 。你的系统必须做那些事，好让用 
例能真正 运作. 即使功能性不总是任何特定用例的 
清楚.明显的一部分。 


» (2> (liit 
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、奪 闲約肉 据 


I ®): 你不 ft 说我应该可以将系统里的毎一个功能对应 

到用例吗？ 

^: 是的，这还是成立的„系统里的每一个功 ft 至少 

解决用 W 图中一个或多个用例的一部分，但那不表示用洌 
就必《真的 A 接使用功能，许多时候，功能不需要被用例 
直接 使用. 就 ft 够让用 例有效 运作。 

在我们的路线搜索 Si . 没有先表示出地铁线路（我们的 
功能之一），就无法栽入地铁战路《络（我们的用 W 之 
一）， 18是'•栽入地铁线路 H 絡”用例没有任何步*直接 
对应到该功能 …… 用例里的步驟只是假设地铁 ft 路的表 
示法存在. a 此 》 iw 间接使用该功能， 以非显 式方式 《 i 用 
它. 

1®) : 那么.用例是需求？或者.功能才是霈求？ 

^: 两者资是！用 W 对与系统交互的人和物 

而言是 需求. 而功能对系统必《做的事情而言是 
需求，它们相关，往不相同。还有，要实现系统 
的用 W . 你还*要系统功能 (feature) 里的功陡性 
(functionality). 那就是为何你总是能将功能对应到它所 
被试予的能力以及使用它的用例。 


IP ) : 假如找不到与用例对应的功能.甚至是间接对应 

的功能.那会如何呢？ 

^ : 你确实应该看看该功 ft. 碥定它真的是系统所 
需要的部件.你的客户（以及他的* 户） 只通过用例与你 
的系统交互。因此，假如一个功鼈连间接帮助用例都不可 
能.那么客户真的不会看到任何好处 s 假如你认为有个功 
ft 真的不会影嘀系统如何被使用及表现，就跟你的客户 
讨论看看.若是该功能无助于系统的改善. T 别害怕 蜊除 
它. 

你的事，芮夂> 是总 
直暌尽硖在你的芹例 
里，芹例裒矛系濟知 
何衹僬 a 

伹它们扣伺的方 
瓦 
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我们开始渐人作境了，有了用例 ftl, 你已经准缶好要将问理分解成较小 
的功能性片段，有一些方式可用于任何应用程序， 然而我 们在此的目的 
垃保抟路线拽索器系统 尽歎換 块化，那衣示将不 N 的功能性片段保持分 
离——毎个換块应该有申.•的职贵。 

继续往前，将路线搜索器系统分解成4个不同的模块 （module) 。仔细想 

想分解系统的最佳方式 . 它不必与你的4个功能 相一致 （即使它珥能 

会）。 



OOA&D 生命周期 


在空络 f 写下此 
徬缺吒 *；： 事的名 





分解 




我们开始期人佳堍了,有了用例图,你已经准备好要将问明分解成较小 
的功能 ft 片段. 



你的铝 f - 

我们正在使用哪个 oo 原则？ 

你认为我们在使用哪个 oo 原則来分解路线搜索器的功能性？勾选出 
你的答案吧。 

□ 单一职 责原则 □ 委托 

I □不自我重复 （□多态 

封装 Q Liskov 替换原则 
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在分解问题与编写用例之间，你常常必须 
做些额外的工作。 


你刚刚发现以 OOA&D 方式编 ii 伟大软件的流程 
中的“神 秘步®■•: 

我们右的7移 s 
-1 先法镇写较钤的鬌求 

3 ， 


这4裁们«的必场采 R 



«) 


1 «»» «•»• 

** ««»« «« 

假如你卡在编写用例 t . 

向 后退- •步，多來肴- • 

下你 正试糖 解决的 nib 汴没有什么不对。然后 ini 
到你的用例，你会有更大的机会将它编写正确。 

^ 制尖你的铝笔 


1 ^ w 我们正在使用哪个 oo 原则？ 

你认为我们正在使用哪个 oo 原則来分解路线搜索器的功能性？勾选 

出你的答案吧。 


y 单一职责原则 

适委托 

□ 不自我重复 

□ 多态 

d 封装 

Q Liskov 替换原则 


2 不 s 瀟 a*g 



OOA&D 


地铁系统有站点.站点之间的连接及地铁线路（地铁线路是一组 
连接）。因此，我们从想想站点是什么开始。 

it *. ?. 4 * ® (S) 

' .c _^ w OOA&DOval 

i 的-彖 .免一 ^ 

iU 

站点之间的迻揸是什么？ 

―旦你开始添加一些站点，你就要 处现这 些站点之闾的 连接。 

.'人 、+ 的 -砟分 


(is 个部4玷 
«. . <? « # 的 


SimUDucklake ' 


M 铥线路 —注串 的连摟…… 

假如你把•些连接组合在一起，你就有了地铁线路。 


设细 地铁的表示 

在我们能够想出如 M 教人地铁线路之 iW, 需®对两 件事打 诮楚的 a ( ns.<i * 

B 解： iitJH- 个終載入* 

O 押解地铁系统什么 的* 础知 U!。 块代路阑辂 

O ffl 解 3 管理荇栽人一组站点 与 地铁线路时他们会钉的信 




. 池狭 《珞4_(4»的站 
♦.吒 4(44. 


*! 朱 •© 辟 f*E 

I Issf-isE 










OOA&D 生命周期 


尖你的铝 f 

^编写载入地铁线路的用例。 

你应该对地铁系统是什么以及对象村地铁输人文件的格式有了足够的 
理解，那么现在就开始编写这个用例吧。 

栽入地 铗线路 R 络 


4 尖你的铝 f 

解答 


编写载入地铁线路的用例 

你应该对地铁系统垃什么以及对* W 地铁输人文件的格式有了 
足够的 W 解，那么现作躭开始编 y 这个用例吧， 


歩讳 I * 起始条 4: 
載入8 ( lot ^ ei ) K 
■中载入數共 
的扣 丈件. ： - - 



C#ii <孝 雄呒 曾4 fl 姑 
孕稞的 铁*. fir 伢的 一 ^ 1 ' 
用 W 相後 

*@洁。 | 


栽入地锒线路 R 路 

1. 箸 《♦« 供蛄 A 岛孅锇 《»<»*»• _ 

2. 取蛄盎《均。 _ 

S . 系法验《蛄盎》李»在, _ 

4. »班增加瓤的《£«珀供. _ 

5. 系眛重复步 *2^4^ £ 利所< 站&袖 加八。 

6. 暮晚嫌取裊缯加齣珀嫌 》»<«»• _ 

1 系編的靄令**蛊》 _ 

I . 系統 tttfrtAB 鳋 ff 在, _ 

». 系统在 Bft 的珀锇 H 鳍土典»令蛄 A 建 g * a *, 
1 0. 系眛重 氮» «7到9 . tHrtrt 供 as sert . 




& feft »*6 M 10. 供 tt 路轤 加入。 


，奪闲矻匈題 


的 S4 鍵 S 
用例的泠沾 
C- 'H 

達 "SubmayLine" 3^ 

% . 

故； i«r®_ 个连戏， 
#£«连戏兵联 （ 
issoetate) {•) 薄定的 

tt mm 



伐不 必科此 英下 
n*. 

记 < s 时象 村的坫 
戍 g »命行輿 4 


问： 


我的用例看起来完全不 一样. 你们的用例 是唯一 


问： 


我没有把验 证步* 加入用例.可以吗？ 



OOA&D 


采煮着我们的用例是否有效 

我入网络的川例打.-点 g *, 有几组步® tk 。 继续分析川例以 
及幵 始设计 系统*之前，检迕. F 我们的文本文件. 

JJI . 爷! I 寺堪供沭这梓 
的洽•系说散入 8 
(s ， st«m l(wJ««) 
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穸祈与珙计拼囪 

这-次，由你•次处理 OOA&D 汝 w 的两个阶段 • 拧先，你 fj® 对卜 •面的用例进 
行文本分析 (textual analysis ) . 想 出哪咚 可能坫帧选类的名以及哪呰"〖能处 
候选操作的动问。根据 Fifli 的川例. ft 空格名词与动词。 

数入摊锇线路闷络 
用例 

1. 瞀《者« 供 蛣点鸟》«銭》的丈件- _ 

2 . 系珑谈 取蛣&名称. __ 

3. 点曲 *赛在. _ 

4. <■> &缯加新的蛄 __ 

酼重 t »«2 W 4, tW « 省蛄立鑪 加入, _ 

6. 系味 谈取漘缯加的 M 供 《»<«>■ _ 

7 . 系统《取相鐮藥的离个蛄立, _ 

»■ JMfelfttf rt&BIBff 在. _ 

9. 系 醜在丨 BWWOtt 路土灼达个 建 g 新 嫌纒， gjsifeffa . 
to •系 »重>»職7«», tHitW 银 M 赡史 《• _ 

11 • 系 fett »«« wio . tw «< w « a »» 加入。 

名词 （候选类）： 


动词（候选操作）： 
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继续进行初步设计 （preliminary design ) • 使用你从用例所得到 
的候选名词与候选动间，在下面绘出类围，表达你认为地铁系统 
以程序代码达換 (modeled in code ) 的*点来看像什么。使用关眹 
( association ) 与其他 UML 表示法将你的设计表达淸楚且可以 理解。 


丨糾 


'捎个《分€ - 

读!4分 (domain Anatysii ) 



« •分* 纛* «蝤分析 



…… S (4 个部分4初 

>__ 

tm 





分析与设计拼田解答 
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使用或者不使闲 Line 类……那 
I 个问越 

ft " fi.Ill 例并 -11 想出我们忠要 Station . Connection 
'.j Subway * (这 《?蛙系统的基础），这是相勹简电的艰。 
但足我们气时决定不创达 Lin * 类，相反地，只足炝砧•个 
连接 《 f • —个线路 名称： 


st « i »* 的 (ineName 
*.5-.. W « 子耗金 ^ 


Connection 
stationl: Station 
station2: Station 
IlneName: String 
getStation1(): Station 
gelStation2(): Station 
getLineName(): Siring 


你的珙计决第 
J £ 该基子你的 
系银扣何祓俱 

00屌则。 


我们作这样的决*足根据•件 呶： 我们知道系统将 
如何被使用。在对 ft 村旅游公司的®始工作说明 
(第488页>1|〖，我们被 ft •知_要丧示地铁并 R 取泔 两站之 fill 
的路线规划。 •!! 有 J * 路线规划的结 *：, 就能够简吶地向毎 
个连接询问它所 W 的地铁线路，实阮的 Line 戈似乎没什么 
需耍的. 
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I®) : 我发现'•验证站点存在"的动词.然而此操 ^ : 噠.你最近一定絛了 构或算法的课 

作出现在你所设计的类的何处？ «!是的，你可以使用 graph 来表示地铁，6•郎种情 


^ : 我们将此操作建樸成 Subway 类的 

hasStationO . 你也可以将它你为 validate (} 或 
validateStation () ,但是你应该总是试 S 让 C 序 
代码尽*具有可读性， 

I®): 你可以多谈一些如何在用例中显示这些重复 
的步* 吗？ 

^ : 很多时例有一 to 步骤需 要被重 1. 但是 
在用例中没有标准的方法将它显示出来.因此.我#1 
就 a 己未鴆一个 《 t ! 用例的要点是给你提供一 》* 清_ 
的！ Mt . 说明你的系《■应该做什么，而我们认为 夂示 
昴姿 玄1 少*蕞清晰的方式就是写下"玄4步 *7 列 
9". 

I®) : 我一 直在想地铁的表示，对我而言. 
它看起来很像 graph 数据结构 (data structure) 
(译注 6) 。我们为什么不使用 graph 呢？ 


► 译注6:有一种数据找构叫做 “graph ". 是由 node 与 
具有方向的 edge 组成的。每一个 node T 经任意 
ft 0的 edge 连接到其他 node。 》外. edge 也吁 
以有标 *• 你为 "labeled edge". 


况下. 每个站点都会是一个 node (节 点）， 而每个连 
接可能是一个 labeled edge (其名连接> t 

1®) : 那我们为什么不在此例中使用 graph 数据 
结构？ 

^ : 我们认为在我们的惰况中使用 graph 是 
••杀鸡用牛刀”，假如你己经知道 graph , 
node 及 edge . 而 i 碰巧有栩关的 G 序代码在手边， 
昂就使用它吧.是从我们的点 来看. 针对我 
们的*求改写 graph . 会比单 tt ■地想出一* 角单 
的 Station - 与 Connection 类要多做很 f 工作，就 
像在设计阶段的（几 乎） 所有其他事一样.解 决问超 
的方法总*不只 一个， 你需要选#边 合休的 方法， 

1^) : 你的整个 graph 问8把我弄昏头了 。这一 
切关 node 与 edge 什么事？ 

^: 没关系，你不必为了了解和解决此特定问題 

而知道 graph。 完全不用担心它，至少一直利我们准 
备好 《Head Firsl Data Structure》 这本书。（有人感 
兴越马 ？ > 


ft 们的 a 开** 在这 4 …… 





OOA&D 生命周期 


^尖你的铝笔 

*■ 编写 Connection 类。 


使用右 边的类阁，将正确柷 汴 代 码填入 T 列空格以完 
成 Connection 类, 在翻到下 M 看我们的答案之前，务 
必让你 的类能够编伴成功。 


public class Connection ( 
private _ _ 




public Connection)_ 

this._» stationl; 

this._= station2; 

this._ = lineName; 





.0 


public 


.0 


I ^ W •分; t * 析 
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编写 Subway 类 

接—卜'来®任场的 JiSub*»y 类本身。完成 
Station 4 Connection 以及 ft 好的类图之后，这甩躭 
没有什么令人惊 W 的事 r : 

public class Subway ( 

private List stations; 
private List connections; 

public Subway () { 

this.stations = new LinkedListO; «_ 

this.connections = new LinkedListO; ^ - 


public void addStation(String stationName) 
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对象村地铁的兵注要点 

(Subway %) 

我们放了几个新尔内到 Subway 类中，你会 fi 到这段 fi! 汴 
代码： 

Station station ■ new Station(stationName); 


例如.创达新的 Connection 时，我们有像这样的程序 
代码： 



许多程序设计师会用 stationName. 迭代 Subway 类中的 
stations 列表，找出名为 stationName 的 Station 对象。 
然而这会花+少时间，其实有史 w 的做法。还记得我 (na 
怎么定义 StationKJ 屮的 equalsO '-jhashCodaO // 


Station 
name: String 
getName(): String 
equals(Object): boolean 
hashCode(): ini 


-蛀來 ijt , f 琢谂 的*<!“《1*() S S 栓 t 
5 f 个的象&8巧阎一个的象…… 
» S ) iiiz . 只 s 老用 《 同的 
内 «*. 我们在此*用* 

( ft 较 ® 个 SMticm 时象的方式 .： 


这两个方法让我们告诉 Java, 在比较两个 Station 对象 
时，只要看看它们的名称是否相同即可。假如名称相同， 
即使两个对象并非引用相同的内存位罝，也应该被视 为相 
同。因此，代替/£ Subway 类的 stations 列表里寻.找特 
定的 Station 对象，只是创违新的 Station 并且使 用它会 
非常简单。 


因为覆盖 equals() 与 hashCode(), 我们可以节省 
搜索的时间 以及减少程序的 复杂性 。你的设计决 

策应该总般_魏更好更复杂或更 ⑽- &巧的°说^以㈣㈣是比 

难理解。 public boolean equalsIObject obj> ( 

return (this ■■ obj);) 





Java 的軚认 equalsO 实现什么 
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f Station I_ 【 Station 1 

I name = Heights" fc 


ft . f £ 它们？ 1 用 7.® 的内 (5 M …… ® rt /!■_ 两 I 站点不相同. 

e^uAlsO^iZ : / ' 

Object.equals() 这的子 A 们的枝 

存代 s # 现來说 

我们的 equalsO 实现 f 十么 . 4个问 * 



(Station I 


裁们的 *«“*<〆)燧本* mttftt ' 

莽传馑 的#础工_ . *74 内存但 ' 


‘ Station.equals() ^?*/ ? St<t，0 " e9 


l°i : 这跟 OOA & D 有什么关系？ 

^ : 这是让 OOA&D 有用的 关鍵： 因为我们理解我们 
的系我们明白 ft 如兩个站点具有一样的名称，它们应 
该被视为一 样的， 而 i. 我们的设计能够根 据它们 的名称 
来比杈站点，而不是根搞它们的内存 位置. 设计因此而获 


因此 • 花费在需求以及理解系统上的时同让我 *1 的设计史 
好，結果让实现此设计 t 得同单 很多. 邶是 OOA&D 的力 
量： 你可以将系 tt •的知识抟 化成炅活的设 计，甚至最后得 
« 较 千冷的《序代码——全都是因均你 花了时间仔切 聆听 
客户. 收集 需求， 而不是一 头理在 IDE <* 成开发坏境） 
并鍮入一堆《滲代妈. 
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抽象化 邙的类 



Jill： 那么,你是在把应用程序的内部暴露 (expose) 出来? 

Joe： 咳咳……不大确定你适什么怠思，不过听起来不*足我想要的。 
你到底蛙什么息恩？ 

Jm : 嗯，來程序代码，嬰栽入地铁，根本不必用到 Stalionij 
Connection. 你可以 MiMI 用新 Subway 类中的方法 • 

Frank： 这跟我 (fl 所建议的有什么不同吗？ 

Jill： 假如采用你们的想法，使用 Subway 类的人也必须使用 Station 与 
Connection*. 在我们百前的版本里，他们只需要使用 String: 站点名 
称 ij 地铁线路名称。 

Joe： 不好.不好， W 为…… 

Frank： 等等,我想我惰了。他们的程序代码会 K 我们的 Suuion 与 
Connection 类的实 现绑 在•起， W 为他们必须 rt； 接使用这两个炎. 

Jill： 正确!然而使用现有的版本,我们能够改变我们的 Station 或 
Connection, ifti 他 (fl 的程序代码会保 持不 变，因为他们的程序代码足 
从我 ff I的 Station 和 Connection 实现中柚离出来的， 
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保护你的类 
(还布窖户的类） 



你应该只将寮户霈要与乏夯互的 粦暴霹 
绘事户。 

方 与著户矣互的类可％在对 箸户 綠移疼 
代碚影响最介的憒况 T 衹玖^ 



載入地铁 

SubwayUader 类 

我们儿乎快完成第一个迭代与我们的第一个用例了，所 
剎卜‘的只垃为 Subway Loader 编码。它根据我们从对象 W 
旅游公 w| 幸到的测 试文 件栽人地铁。 

public class SubwayLoader ) 
private Subway subway; 



public SubwayLoader()( 

this.subway = new Subway0; 


public Subway loadFromFile(File subwayFile) throws IOException { 
BufferedReader reader = new BufferedReader( 
new FileReader(subwayFile)); 


loadStacions(subway, reader)； 



while ((lineName != null) && > 
loadLine(subway/ reader, lii 
lineName = reader. readLine<); 

) 

return subway; 


f 二工心 


private void loadStations(Subway subway, BufferedReader reader) 
throws IOException ( 

String currentLine; 

currentLine = reader. readLinel); ? • 入赵 # 


while 

subway. addSta 
currentLine = 


.length!) > 0) I 
mtLine); 
reader.ceadLineO; 




private void loadLine (Subway subway, BufferedReader reader. 

String lineName) 

throws IOException ( 兴 们该进 第一个玷 #. 

String sCationlName, stacion2Name; / — n _ /■ ■社 

stationlName = reader.readLineO; 爲该道后该的 _ 丨站 

station2Name = reader.readLineO; * 

while ((station2Name !- null) ££ (station2Name.length!) > 0)) { 
subway. addConnectionlstacionlName, 

• stat ion2Name; <— 

=reader. readLinel); 


n 妗虧栌 》 二个玷系. 


…… . 使用劣 坫铗 
技路名彷坩釦 _ 个舶 a «— 
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Q 


方法祓镔 

宋你调用 SubwayLoader 的 loadFromFileO 并 H_ 给它我们从对 象村旅 
游公 iil 拿到的文本文件时，到底会发生什么亊。你的任务是将本沉底邢的 
磁铁（它们 对应到 SubwayLoader 与 Subway 炎） 放到它们在文本文件 !U 将 


被《用的那-行 旁边， 







载入地铁 



方法磁镔解著 

來你 WIWI SubwayLoader 的 loadFromFile(> 并且给它我们从对 
象村旅游公 rfl 拿到的文本文件时，到底会发屯什 么亊， 你的任务垃 
将本！ iillS 部的磁铁（它们对应到 SubwayLoader '-j Subway DJ) 放到 
它们 住文本 文件姐将彼 iBItti 的那•行旁边， 






濟试拼窗 
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你几乎 已经完成了第-个用例.我们的第 
W 法.确认它與的柯效。 


仑迭代！剩 F 的 U 坫测 W 我〖1’1的 


问题： 

你必須测试 ObjectvilleSubway . txt 文件的我人，确认 
SubwayLoader |卜:确地栽入文件甩所冇的站点与连接。 


任务： 

O 增加方法到 Subway , 检査- _ F ^ 给定两个站点及地铁线路的名称时.特 
定连接是否存在。 

Q 编‘<5•名为 LoadTester 的澜试类，内含 main (> 方法，从对象村旅游公司 
所從供的义木义件战人对染 W 地铁系统。 

O doadTaater 1|1 .编 •>.; 程序代码，将来 fi 文本文件的--些站点及迮接， 
与从 SubwayI > oad « r 的 loadFromFil «0 /；•法返回的 Subway 对象作比 
对。你应该 M 少针对3条地铁线路 J •.的3个站点及3条连接进行确认. 

O 运行你的测试稈 汴， 验 in ; 我们真的完成 far -个迭代， 


@ I M ®) 该的用 


»入 w « a 路 b 铕 



R1- 4 S JEWS 
的 _« 分 . 代砝 3 







羽试拼窗解者 


你的 X 作足;测 WSubwayLoader Ij 地铁的&氺，确认你能从文本文件中栽人 
地铁 系统。 

O 增加方汰到 Subway , 检丧一 T 当给定两个站点灰地线路的名称时， 
特定连接是否存在。 



^ : 是的 • 41 如有 Lin« 对象.我们可以使用被传入 
haaConnactionO 的名你对地铁 ft 路进行查讷，只要迭代 
该地 铁拽路 所有的 Connection 对象即可。因此在多飫情 
况下. #1 如有 Lin •对象 .hasConnection(> 会涉及较少 
的遑代并 iL 杖快返 Wtt 果. 


好主意 • 然而如果我们犮现应用《年的其余部分也需* 
h M Conn « ctionO 方法，就有可能需要田过头来重新考* 
这件事. 
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* 编写名力 LoadT«st«r 的测试炎，内含 main(> 方法，从对象村旅游 
公 iVJ 所提供的文本文件栽入对 ft W 地铁系统. 

>在 Lo«dT«»t_rm 编 ‘*•; 程序代码，将来自文本文件 m 的-哼站点 

及连接，与从 SubwayLoad 籲 r 的 loadFromFil*() 方法返时的 E 本邛鬌龙 该一普 
Subway 对象作比对 • 你应该至少针对 3 条地铁线路上的 3 个站点与 3 条 沾夸 . 矢逄级 . «# 它们 4 
连接进行确认， 8 味打破 戤入 

____ 

public class LoadTestec { 

public static void main (String!] args) { 
try { 

SubwayLoader loader = new SubwayLoader(); 

Subway objectville = 

loader. loadFromFile (new File ("Ob jectvilleSubway. txt"” ； 

System.out.println(~Testing stations..."); 
if (objectvi1le.hasStation("DRY Drive") && 

objectville.hasStation("Weather-0-Rama, Inc.") && 
objectville.hasStation(''Boards 'R* Us"))( 

System.out.printlni"...station test passed successfully."); 

I else ( 

System.out.println( w ...station test FAILED."(f 
System.exit(-l); 


''Infinite Circle", ''Rumbaugh L 


e.printStackTrace (System.out); 


当前位 S ► 









» 试与迭代 



羽试拼戽解著 a%) 


你的工怍坫期试 SubwayLoader 以及地铁的衣, | i . 确认你能从文本文件战 
入地铁系统， 

O 运行你的测试程序，验 iff 我们真的完成 I * 第 1 .个迭代。 




* •••••• ^ 


哝- 

A ws 编^测试用例 • 取得所冇站点接并将它们 
输出.以验证整个地铁线路网络被正 D » 栽人， 


是泫逬行第二个迭代的时候5 

我们的澜试 iiE 明我们真的完成 r 第-个迭代 • 用例 
“栽入地铁线路 W 络”完成，表示该进行第：个迭代丫。现在我 




下一个用例成功 *14 C 


電求阶 aft4S . 


530 




不过，在第二个迭代孖 飽之前••… 


tr-B 经奔成3 一个 很长的 铯代, a 
炒3—些很#的工作。 俜下弗 ，< 
S ： jtrr , 吃点简餐或者喝点水。 
静生蚀 1, t =» b „ 


4零 

to 


—旦休息奔毕，馱孥着翻到 T — 页/ 
让我 们着手迸行最厉-个芹梦九 准考 
妗3鸣？进行 T — 个送代吧。 
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聚箨子程序代码，然后聚焦子窖户。 

爯聚锋 子程序代码，然后爯聚链子窖 
户 . 

M 想第502«,气我们开 始将应 用程序分解成不间換块时，我 们实标 上垃在 
谈应 用程序 的结构以及如何分解我们的应用程序，我们在 Subway 換块唞介 
Subway 1 j Station 类， 在 Loader 模块甲. “ SubwayLoader 5 S , 换句话说， 



*ei=. »们 



mte 汴我 ffI 处押用例时，我们的热点是客户如 h 使 w 系统——我 们探究 
嬰我入地铁系统的输入文件的格式，并且汗始聚热 r •客户与系统的交 
a. 内此，我们实标上_ . ft 在程序代码（在 “h 埋 分解”阶段） 与客户 
(在“潘求”阶段）之间來來冋问： 


|⑽ 
I 列表 


这 个孕 

代«以及扣何分《劝 




用 M9 



问 * 分 * 



户釦何 璉用我 ( H 的 
欸件的。 


*« 領 域分析 


扣步设 it 


在你开发软件时会有许多这类来來回回的事„你必须确认你的软件在做它 
该做的事.然而真正让你的软件做事的是你的程序代码。 



侪的积黄是 在确认 寧户得到挝要的功熊惟与 
确保栈序代碚兵有灵沄惟夂设计象势;取 
得毕衡„ 


当前位 a 
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抑与玫 计_ — 

垃该为系统进行领域分析与设计的时候了.利用下面的用例，想出 
候选类与候选操作，然后对右边的类图进行你认为擗要的 史新。 


取得路线規划 

用例 

1. 旅行社送绐系统起点站鸟终 点站。 

2 . 系珑验证起点站鸟终点蛄《者蕾徉在子 

_ 

3 . 系统计 箕从起点蛣£终&站的踣 au 

4. 系统输出它所计篝出的 路线。 


名词（候选类） 


动词（候选操作） 






类图 



尹析 a 珙计# 固斛考 


戧们知 i £ 我们 f «_ 个# i *. 
- 2 U. s«6»«, itfcff 珞 «. « 
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迭代 (iteration) 

让问涯比餃容易 

七一豇的* 围实际 I-. 4 第-个迭代的* R) 没有太大的不同 



- 完成第一个迭代，后续的迭代往往容易很多，因为你 
所完成的I午多事 it 后续的迭代更容 a。 






我 <na 有 xn 
« « . 氓«不氓 
夺* ■•个 a 代中 
<— 免#炎的 徉多 

成5 <砟分 .我们 
甚 i 3经淖备耔了 


I ^ »wg 


j » 们油 备好* 迸 》•) H »设…… 
«*4 fci 2 代的进行呔第 ■■个违代桷 
(fit. 也; a 穷晬么多寧*值。 

\ 


«求 領蝤分析 扣步设 it «« 
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实现： Subway.java 


计算两站之间的路线进•个特別 W 手的问娌，我们陷人了在第 
515 WifiStei 谈论过的 graphN 题中 • 为了帑助你完成，我们已经 
包含 J" 一现成叶用的程序代 Pi (ready-bakc code) ,让你用来 
取得两站之 ful 的路线。 


public class Subway { 
private List : 
private List ( 

private Hap r 


现成玎用的 
程序代码 1 


M,p 徉噼 5 _个站 


现威 g 用的《 4 代《 

6„ k . cod .) 4 我 OBtt 華 

f 的内窖 将 它婧入成老 认 ㈠** 11 
fi, st 下戴 * 養鈑本 W 


public SubwayO { 

this.stations = new LinkedListO; 
this.connections = new LinkedListO; 

thia.network = new HashMapO; ^ - 



" addStationO, hasStationO 与 hasConnectionO 方法的 W • 代码保 W 不变 


public Connection addConnection (St ring stationlName, String station2Name, 
String lineName) { 

if ((this.hasStation(stationlName)) && 


(this.hasStaCion(station2Name)))( 

Station stationl - new Station(stationlName); 
Station station2 = new StaCion<station2Name); 



connect ions, add (connect ion); 

connections. add (new Connection(station2, stationl. 


connection.getLineName 0)), 

addToNetwork (atationl, stati.on2); _ _ 

addToMetwork (station2 , stationl); 

return connection; 

\ else { 

throw new RuntimeException(''Invalid connection !")； 


在 if 加逢戏的.裁们* t * 扣 
§ 噠的玷魚以 a 含们如 仞 连戏 
的 ” etwoib M«p- 


Station station2) 


-社才沾 （ t ) w Ti5 


List connectingStations - (List)network.get(stationl); 
if 0connectingStations.contains(station2)) { 


connectingStations.add(station2); 

} 

else { 

List connectingStations = new LinkedListO; 
connectingStations. add(station2); 



我们 ■以玷魚 办鑪 （ fc *») .以 
fe 1 W lii 的鰣 <5 玷 .# •的 衫表綷 
<t (,•(“《). 不* 铉罈一条 玷枝线 
路 1 雎。 








取得路线规划 ：续: 


)else if (!reachableStations.contains(neighbor)) 
reachableStations.adcMneighbor); 
tmpNextStations.add(neighbor); 

previousStat ions .put (neighbor, currentStation); 

现成玎用的 
程序代码 



// We’ve found the path by now 
boolean keepLooping = true; 
Station keystation = end; 
Station station; 



while (keepLooping)( 

station = (Station)previousStations.get (keystation); — 2®/* 戟们 
route.add(0, getConnection(station, keystation)); 
if (start.equals (station)) I ' 

keepLooping - false; 




private Connection getConnection (Station stationl. Station station2) 1 
for (Iterator i = connections.iteratorO; i.hasNextO;)) 

Connection connection = (Connection)i.next!); 

Station one = connection.getStationlO; 

Station two = connection.getstation2(); 
if ((stationl.equals (one)) S& (station2.equals (two))) { 



return null; 


keystation = station; 


return route; 




赶筘孖 ' (unmiiJ) 
#珞《4釗遠 一个从 

表。 
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你 (ft' 


㈣ 的 



有时候，完成工作的最佳方式就 
是找到其他人已经完成的该工作 
的成果。 

在此阶段，我们给你一段取得两站之间 
的路线的程序代码，这或许看起来有点 
怪，然而那是构成一位优秀开发者的一 
部分： 愿意四处找找困难问趙的现有解 
法。 

事实上，在实现能够用在地铁系统中的 
_ Dijkstra 算法版本时, 我们也 获得了一 
位大学生的#忙的！ > ,当然，你 
或11••能为毎•个堆 埋想出 fl 己的®创性 
解法，然而如采某人已经帮你完成该工 
作，为什么不把它拿来用呢？ 


有时候，特定洵拯的最偉栈序代碚5/经裱编 
WU 3 „ 假扣弟 经枘有有热的解法，馱 
刿哮是要令己编写。 


I 

I fi-ft 


»«® 闷#分 K ft* ««分析 扣步设 i+ 


«板 
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输出拼窗 


你几乎快完成了！有了 Subway 41 柯效的 getDiractions (> 方 
法 . »)n - 个獎实现的功能是将路线规划輪出，你的任务是编写名 
为 SubMayPrint*r 的炎，它接受从 g*tDir*ctiona (> 返回的数彻 
结构 （ Connection 对象的列 表）， 冉将该路线规划输 :IU 路线规 
划应该被描出到 OutputStream, /KSubwayPrinter 丈例被创让 
时， OutputStream 披提供给它的构造函数。 

这里是 你应该遵循的 SubwayPrinter 类图： 


aift 谂. 


-sss« 

射的该集 8 


ftion 2 








擁出拼固斛著 


下 Ifiiffi 我们所编 1 J 的 Sub «» yPrint * r 龙.你可能想出 J * 略冇不间 
的方式 迭代整个路线列表，然 Ifti 你的轴 出在逻辑 上应该与我们的相 
符才 算得到 满分喔 I 



public class SubwayPrinter ( 
PrintStream out; 


public SubwayPr inter (OutputStream out) 
this.out = new PrintStream (out); 


window) .‘ 


public void printDirections(List route)( 

Connection connection = (Connection)route.get(O); 
String currentLine = connection.getLineName(); 
String previousLine - currentLine; 

out.println("Start out at " + 4^. - 

connection.getStationl().getName() + n ."); 
out.println(''Get on the " + currentLine + '' head: 

connecCion.getStation2().getName() + 
for (int i«l; i<route. size (); i++) { 
connection = (Connect ion) route.get (i); 




.1(4 AS 1- 寿的 * ~ 

条他技 《 路 . a** 
枳枝 的下一玷， 


if (currentLine-equals(previousLine)) - a 炫 ; 

out-printlnC™ Continue past '' + 喊铁 f 

connection .getstationl 0 .getName () + 

} else ( ® 如 4 阌 一条他铗线路 

out.println(''When you get to ~ + 杖 _o. 狳出玷 盘名枋 》 

connection .getstationl <) .getName () +、、， get off the " - 
previousLine + 




鬼如珀祅钱路竒 
. 変. 铨出如 何样乘 
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最后一个谢试类…… 

我们现 在要做的躭垃将所有亊情组合起来。卜 •面垃我们编写的 
用来典入对 IfeW 地铁系统的 SubwayTest«r 它接受从命令 
行輪人的两个站点名称，使川新的 g « tDir « C ti 0n » (> 方法与 
SubwayPrintar 龙取洱并输出两站之间的路线规划结 *. 

public class SubwayTester ( 

public static void main(String[] args) { 
if (args.length !■ 2) { 




System, exit (-1); ^ 

: ry < 给 这个邮 

SubwayLoader loader = new SubwayLoader () : ... 

Subway objectville - - - - — 我 (H 料 6iiW 该 i3iS 

loader.loadFromFile (new File<~0bjectvi 1 leSubway.txt")); 个.我们和 这祕故 

系统 Wft 入注作正當 

if (!objectville.hasStation(args[0]))( 

System.err.println(args【OI + " is not a station in Objectville.~); 

System.exit (-1); V: 

)else if (!objectville.hasStaCion(args[l]>) ( 

System.err.println(args[l] + " is not a station in Objectville.*); 
System.exitM); 的也紐料供的 

» 个以 <3 喊後•系统 
t )14 

List route = objectville.getDirections(args(0]/ args[l ”； 

SubwayPrinter printer = new SubwayPr inter (System. out); _ 个有从的誌♦•我 

printer.printDirections(route); tj T ^ < ― 二 -i 於在 

> catch (Exception e, , 叫 ㈣ 料邮路 


printer.printDirections (route). 
I catch (Exception e) { 
e .printStackTrace (System.out); 
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拜访对象村 

itli B 羞羞对象村 r 






OOA&D 生命周期 


Ie ] 到第487«,我们！ !1 时要求你想-想，I午多你.直在学习的东西该对应到 
Flftf 的 OOA&D 生命周期的哪个部分。既然你 Li 经又写了另一个伟人软件 
的片段，应该巳经准备好做这个习理并 a 看看我们是怎么作答的。再练习 
一次吧，在完成本章之后，有没有变电你原先放 g 磁铁的位置呢？ 

喔.别忘 r, 你可以在毎个阶段放 s —个以上的磁铁，而且有些磁铁你可 
能想要使用超过--次。 


OOA&D 关系到选择 



OCM 及 D 糍锈斛著 

你的 fr : 务垃尝 W 将磁铁放 ft OOA&D 生命周期的正确阶段。你《|•以在 
毎个 阶段放 W •个 以上的磁铁,比较. K 你跟我们的答案吧! 



I ®): 我好像可以将所有的磁铁放 a 在毎一个阶 

段那不会是对的吧？ 

^: 抓是 吋的. s 然在良好的开发用期里确实 

有一些■基本的汾段 • 但你 T 以使用你巳经字到的关 
于 OOA&D. OO 希則，设计、分析.需求的东*放 
到每一个开*粉•段. 

编写伟大软忤最有效及最成功的方式.是尽*利用 
你所能利用的工具.并且在每一个开发阶段选择任 
何一个（或 多个） 采用.工具 越？. 就有趄多方式 
能检查及处 a 问題，那表示你被卡住或不知道下一 


00 A & D 兴系列泠多迭择,, 
铯对浼有唯―芷确的方式 
弗斛夬洵拯，因此妫有的 
迭梅趙多，馱越有机会为 
毎个洵翘找到&解法。 





OOA&D 生命周期 


第三次迭代，布人要试试吗？ 

不，我们不再投人到电多的设计 NIS 中，然而你要知进.路线搜索器 
应用程序的设计还 打1 午多可以改苒的地方。我想我 (n 只会拾你.呰边 
议.以 应对万 •你坚持耍进行下一轮 OOA&D 开发周期的怙况， 


让栽入更爯扩展性 

现在，我们只有单-的类来处理栽人的工作，它只接受 Java 的 File 
作为输人。看看你是*可以想到一个解法，让你从不|0|类喂的輪人源 
(inpul source) 栽人地铁系统（试着从 Fila i-jInputstream 开始）， 
并且让增加新的输人源（像数据库）变得容易。记住，在你增加新功 
能时，你会想要把对现有程序代码的改变减到最少，因此你最后可能 
会想要运用接 n 或抽象的基类。 



00 A &0 島体件4—个 
永久 a 營的……伢未 

玱4你的 


免许不商的输出源（及格式 f ) 

我们 M 能将路线规划的结果输出到文件，而且路线规划的结果是以特 
定方式格式化的。看看你是否能设计一个灵活的 Primer 模块，让你将 
路线规划的结果输出到不同的输出源 （像 File. OutputStreamtj 
Writer). 并且是以不同的格式（也许是符合我们现有内容的详细形 
式. （乂仅 》. 示在哪 HUt 乘的精简形式以及要给』 t 他程序使用的 XML 形 
式）. 



夺考《澤入; 4 式》 

! S ； i . «« 你如何** 杜»法- 
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OOA&D 填字游戏 



00 A 邛塊$游戏（最终锣） 

是的，真 伤®, 你#到的正是本 书最后 的填字游戏。深呼 
吸一下吧，我们已经尽置把这一回塞满 r — 些，让你玩久 
一点。好好享受吧！ 
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横排提示 

2. All of your features should mop to these, at 
least indirectly. 

3. When you override equals() in Java, you 
should create 0 related implementation of this 

5. Your features reflect this in your 
application. 

6. You do this once you complete one feature 
or use cose. 

10. A feature list focuses an what your 
software_. 

12. When you complete this phase, you're 
either done or need to iterate again. 

•5 - Break your application up into these, based 
on your app's functionality. 

17. Understanding how a system is used should 

help you moke better_decisions. 

18. The approach to development we used m 
this chapter (3 words). 

19. Never b« afraid to use a_to o 

problem that someone else came up with. 

21. Vour design decisions ore based on haw this 
is used as well as good OO principles. 


竖排提示 

1- Make a list of these tc 

4. You usually create this type of diagram 
based on your domajn analysts. 

7. This iteration is usually the toughest. 

8. OOAAb is about giving you lots of these. 

9. You sometimes hove to add a step to da this 
with your problem before writing use cases. 

10. The kind of analysis thot involves speaking 
to the customer in language thot they 
understand. 

11. This proves that your implementation is 
working. 

13. The nouns in your use case are these types 
of classes. 

M. You have t。balance what the customer 

wants with your software's __ 

16. This is the stage where you apply good 00 
principles. 

20. Use cose diagrams focus on how your 
software will be 
















旅程未结束 


OOA&D 生命周期 



现在，将00八备1?迗用到你 f 3的项 ©ilf 

很高兴你来 到对象村，现在要送你离开，感觉貞的有点舍不得。然而天下没 
有+敗的筵席，敢烺值得高兴的是你可以将所学的•切运用到自己开发的项 
自上，所以别忘接再厉，继续使用 OOA&D. 在本书的末尾还有- .咚难 
能可批的 东两嬰 给你，接荇便垃将所有这些新想法付诸实现的时候。我们 
迫+及待想打召亊怙会如 何发 城， W 此别忘 77( •: Head First Labs 网站 (http:// 
wwww.hcadlirstlabs.com) 丄 _.tft 我们-点反饿， il: 我 ffl 知 jfiOOA&D 进没 舆的 
It 你的人生变得多彩。 










附录 1: 本书遗珠 

前十大主题 

(本书未涵盖到的) 


超过550页，还是有些事情没被涵盖到。即使最后这10个主题只是 


稍微提-下，我们还是想 it 你在离开对象村之前，对这些主题拥有多 


-- 点的信息。但是，嘿嘿，在 “OO 大灾难！”节目的广告期间，你 


还有-些亊要谈……谁不#欢时不时躭来点刺激的 OOA&D 谈话？ 


此外，一且你完成这个部分，剩下的就是另一个附录及索引……然 


后，你便真的完成 r 本书的阅读，真的！ 


信不信由你，还有很多东西要探究。 是的，即使已经阅读了 




*1. IS-A^HAS-A 

在 oo 编 w 的汗发周期 ift, wr (益五便会听到有人 在谈 is-a 与 
HAS-A 关系. 

IS - A 涉及链承 

通常， IS-A 关系到继承 （inheritance) • 例如： Sword 
(剑） 1S-A (是） Weapon (武器）， 因此 Sword 应该扩展 
(extend) Weapon 。 



HAS - A 涉 及组含 成聚含 

HAS-A 关系到组合 (composition) 与聚合 (aggregation) ,因 
此你可能 听到： Unit (战斗单位） HAS-A (有） Weapon 
(武 器）， 所以 Unit 由 Weapon 对象 组成。 竒吋 fi!. ij 破你巧 
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IS - A 鸟 HAS - A 的问题 

我们没有涵36太多 IS - A 与 HAS-A ,进因为它们在某些状况 f 会容 S 失 
收。例如，考 16你为几何形状 （ ffifCircl *、 R « ctangl«'j Diamond ) 
进行违校的情况。 

假如考虑 Square 村象，你可以运用 IS - A 关系： Squ » r * (正方 
形） IS-A (是） Ractangl •(矩 形）， 因此，你应该让 Squar •扩 
展 Rectangle , 对吧？ 


setHeight(int) 

|setWidlh(int) 




setHeight(int) 

IselWidih(int) 


然而，还记得 LSP 吗？子类®应该能咎代其基类因此. Squar . )，5 
该能 K 接替代 Rectangl .. 佴是这里的程序代码会发生什么事？ 


Rectangle square = new SquareO; ib 方金这 ® < 今么 

square. setHeight (10); 
square. setVJidth (5); 


System.out.print In ("Height is " + square .getHeight ()); 



这里的 N 题是，当你以 Square 的 setwidth <> 方法设定宽度 
时，正方形也将必须设定其高度，因为正方形的宽度等于髙度。因 
此，即使 Squar * IS - AR * ctangl *， 它的行为并不像 Rectangle 。 i ： 
述 getHightO 调用将返回5,而非10,这表示正方形的行为不同干矩 
形，无法替代它们一这违反 LSP 。 

使用继承的时机是当一个对象的行为类似于另一个对 
象的行为时，而不只是因为 is - Aii " 成立。 


f f 1 的4 
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吆 .用例格式 

M 然用例有_ •个不错的标准定义，但是并没有标准的方式来 
编写用例。 r 面是几个不同的编写 方式： 


Todd 乌 Wna 的狗门， % 2.0 te 


构门要戗的搴 



l . Fido 在叫， 砂鍚 S 出去。 


这4我 们 0期在速用的格 

2. Todd A Wna 咐到 Fldo 在叫。 


式. 甬辈嚷 n . 以歩》4*站. 

3. Todd 或 frina 按 " F 遥控器按钮。 


1用子 太部 分的找况。 

. 夕 

4 . 狗门打孖。 

5. Fldo 路出去。 

6. FWo 办它 的擧。 


Hi 比 ti 抡後的 风格 .系 

6.1 轉门 t 劫兵 闭。 

6.2 Fido 在叫.砂着 S 进采。 



6.3 Todd 成 Irina Fido 

次〉。 

Todd 与 Wwa 的构门，蓠么 0 肱 

6.4 Todd 或 & ina 垵7通控器垵 


狗门要傲的事 

6.5 狗孖打孖 （再一次）。 

Fido 在叫，吵羞要出去。当 ToddsUlna - ii 到它 

ZFido © 采、进门。 

在叫，«按7通控器按钮。打开狗门， Fido 路出 

t 狗门 t 动兵闭。 

去。摟著， FWo 办它 的事、 珍来、 进门， 狗门 鱼 
动兵闭。 


倌如 Fido 在外® 待太久，当它还在外 s 时. 


构门«1)动兵闭。 Fido 会叫，砂署 要逬采 ，而 
ToddsUItta 会爯次按 7 遥垃器椬往。打开狗门 

( 

it Fido ® 采、 

进门。 



* 代路《破加 《•) 珀 ® w 朿速. 
HDW . u u - thm ' 的衫式出现， 
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聚恁子交至 

此格式侧* r 聚热在将系统内外部分开，以及系统外邢的畚 
与者如何与软件交互. 


二”… ' e … 



tsfi . 4 -^ 
老在系铗外 " 
«. 沾们值 
用承统或岛 
系统 45- 


Todd 乌 （ Mwa 的狗门，第 2.0 皈 

狗门要戗的事 

-- 参乌者 

系统 

Fido 在叫，吵碁要出*。 


Todd 成 & ina 咁到 Fido 在 




Todd 或 Wna 按 " F 通控器 


按0。 


Fido 跎出去。 

构门打孖。 

Fido 办它的擧。 


Fido ® 来、进门。 



狗门 t 动打孖。 

扩展路径 


假如 Fido 在外®, ffi 构门在它进门前 《 t 动兵闭， Fldo 会 

叫，砂薄要进采。 Todd 或 & ina 会爯次按 T 遥控器按钮.打 

开狗门，让 Fldo 进來。 

」 


To « 乌 Q / m 的狗 

a *°* 响左 

ToU. <HH.tpfido 
的动仃。 


/ e ? ^_ 此格 式科來 a 供 ft « w 方式公*轚代珞 
JS . * S 4 H 它故 B <1 用例的末进。 
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更多的用例格式与反设计模式 


餃正式 的用例 




T odd 鸟射 wa 的狗门 ， % 2.0 K 
~~狗门要做的事~~ 

^主 S 参 乌者 ： Fido 

夺耷辛 次要参鸟者： Todd 乌 Wna 

前 g 彔件： Fido 在岽里，索要出去上麻所。 

目标： FidoJ ： 完涵所，©到象里， Todd 乌 Wwa 不必起 


簕1条4说玥系 
统<5 ft 谂费译鈦 
的条4， 


床孖兵狗门。 


主31路径： 

1. Fldo 在叫,吵著要出*。 

2. Todd 成 W"a Htf>l Fido 在叫。 

$. Todd sX & i » ta 垵 7 遥控思 按钮。 

4.构门打孖。 

SFIdo 路出去。 

6. FW 0 办它的事。 

ZFido ® 来、进门。 

8.狗门6动兵闭。 

扩展 踣径 ： 

6.1 狗门 I )动 兵闭。 

6.2 Fido 在叫.砂«!!进来。 

a jt}5' 在 itt 格式 

J 6.3 Todd 或 （Mwa 咁到 Fido 在叫（爯一次）, 
n ,%9 6.4 Todd 或 & i » ia 按7通控器按钮。 

6.5 构 n 打开（爯一 次）。 


.用例中的《_件葶和 
* 巧 7 龙成 ij 个 0 杉。 


M 有这螫角釗部说 阑一 4» ……由伐（残 Cf . w 老 
板）：*4__神格式*(4舍你们。 
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反设 计模式 

在这本书甩我们已经谈了很多关干设计模式的事，并 a 以这 
样的方式描述 它们： 




设计横式 

设计檎式是特定 类暫问 题的经证实的解 
法，帮助我们以更容易理解.£好维护. 
更具灵活性的方式结构化我们自己的应 
用程序。 


但是，另一种你应该知道的模式类型称为••反设计模式 1 • 

(anti-pattem) : 

t • 反设计樓式 

反设计模式是设计模式的反面：它们是 | 
问 理共同的“坏••解法.这些》藏的危 i 
r ' 险应该被识別出来并且被避免。 ! 


设计榇式帮垆侪诈 
的“ 努”斛法 。 

尽珙计褀式帮妒你 
拯的 “帑” 斛法。 


当你看 见相 同问题以相冋方式被解决，而该解法是 
个••坏 - 解法，反设计镆式便出现了，例如，一个常见的反 
设计模式叫做 “Gas Factory” ，是指过分复杂以至于难以维 
护的设计，因此你会想极力避免 Gas Factory 出现在你自己的 


我们4采 贫场补充这一 
在往 T_ 次的户 JM 
发含 议中. 




H . CRC 卡 

CRC 代表类 （ Class ). 职贵 （ Responsibmiy ) 与协作者 
(collaborator) 。这些卡片被用来取得类，厘消它的职 K 应该是 
什么以及它的协作类有哪些。 
























度置与颗序田 


n 璧 

有时候?14难分 W 你的设计实际上有多么稳定，因为设II•是相当主观 的。 这就是 
度 ft (metrics) 能够 W 忙的地力、 S 然它不提供系统 的整体 围， 佾能报 忙指出 
系统的强度.弱点以及潜在的问题。你通常使用软件 r. 具来以类的源代码为输 
人，然后根据程序代码和它的设计产*统 U •数据。 


然而，这些度 S 不只 是单纯的数字 • 例如，只是计算应用程序的代码行数，而 
没有 Sd 合情境 (context) ,那几乎就只是浪费时间。但是如果去计算毎1,000行 
程序代码有多少缺陷 （defect) ,那就变成有用的信 息了。 


缺陷密度= 


«瘩代砝中盔现的鉍唼 




你也可以使用度 s 来测 a 程序代码抽象化程度之类的事。良好的设计会使用抽 
象的类弓接口，好让其他类能针对这些类编码，而不是针对特定的实现类。因 
此，抽*化让程序代码的某-•部分独立于其他部分的改变.你可以使用-种叫 
做抽象化度最 （abstraction metric) 的东西来脚 H: 它： 


A = N , / N 


N -4 耗 4® 或 
中袖象 皂的技 0( fe 含戏 

o) 。 


N H « 

中*的 S 盎 




ii 个 ft 穹 S 4 介子0耷1 =间 
數 字 表 矛 柚象化《 4 * 
數穿 .) •表 矛 柚象 ftltftfA 


抽象化程度较高的包有较高的 A 值，抽象化程度较低的包有较低的 A 值。一般 
来说，你会想让软件里的毎一个包只依赖 A 值较髙的包，那表示你的包总是依 
赖较为抽象的包，结采就形成能轻易响应变更的软件。 


Raicil NUttin 的半. 

《 Aj “* So <( M«ie 0«« fop >"«" t 》 
内 多島00 有关的 A«., 
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*6. 嘛序思 

在实现 Todd 与 Gina 的狗 f] 时，我们开发了一些替代路径 （且# 代路柃 
本 9 ■还代路 柃）， 为了对系统如何处理这些不 Ml 路彳 4 取得-点感 
觉，使用 UMLMJi 序围 (sequencediagram) 是钉稱 助的。 顒序 ffl •如其 
名： .示发生在#与者与系统间特定交5的一种视觉化方式. 
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*1 拔0@ 

你已经看过了类 ffl 与顺 序1*1, 而 UML 还包含状态机明 (state 
machine diagram) 或状态图 (state diagram, 过去也有人称之 
为 'stalecharl diagram"). 此阁形通过显示不同状态 （slate) 以 
及造成状态改变的动作 （action) 来描述系统的一部分.这对干以 
视觉化方式描述复杂的行为是非常棒的。 

当你有多个动作与事件 (event) 同时发生时，状态图才真正发挥 
它的效用。在右 贾中， 我们处理这样的状况，为游戏设计者如何使 
用 Gary 的游戏系统框架绘制状态图。假如游戏设计者将使用此框 
架， 那么他们所编写的游戏的行为可能就像此状态图所说明的那样。 

里的常用符吾 


代表鈒姥仗态 

((Mttinj 。 








的®® q 羲矗 


Ready to 
Play 




内 <5 名彷 


to ― 


(ttantition) /t 
用《4从_ 个杖态 
«« 成另 一 ii «5 



make move [units able to move > 0] 


搞的名枋. 
ft 杖 5 的 e 6 i 。 


、 d 柱砝表式 
(«««' rrptession) 

场的条 4 








* 8 . 单无谢试 

在毎个处理应用程序的章节里，我们已经构 a /• •■驱 动” 
(driver) 程作以测试程序代码， fft SubwayTastar '-j DogDoocSim 
ul-tor, 这些全都是单元劂试 (unit testing) 的形式.我们以一组 
特定的输入数据或-组特定顺序的方法调用來测试毎一个类. 

虽然这垃了解客户使用时应用程序如何运作的好方式，然而还是有 
一些 缺点： 

o 你必须为软件的毎一种使用编写完整的程序。 

Q 你必须产生某种输出，不是到终端机 （console ) ,就是到 
文件，以便验证软件正确运作。 

o 毎一次运行测试，你必须手动检査测试的输出以确认事情 
正确运作。 

O 你的澜 w 最后将测试大的功能性片段，而不再测试应用程 
序甩所有的较小功能. 

幸运地，有一些测试框架不仅让你测 w 很小的功能性片段.而且还 
支持许多自动化瀏 W。 在 Java 里， 圾受欢 迎的澜 w 框架叫做 JUnit 
(http://www.junit.org) ,它眼许多有名的 Java 开发环境相整合, 
像 Eclipse. 


'常向 〜。 7 理 


1^) : 假如我们在本书正文中所编写的测试在较高层次 
上磽认我们的软件能运作.为什么还爾要更多的测试？那 
些还不够碗认我们的软件能运作吗？ 

^: 我们所編写的大部分測试实际上*在涮试特定的 
场景. 例如.打开 典门. 让拘出去、主人的狗再一次 -)• 
接着让它和来.单元*试，特别是我们在此所淡的，是史 
加蛔擻的.它们《试4■个类的功能性.一次一个 片段. 


两 种类® 的測试皆需*,是因为你无法想到所有的场景， 
无法* 试到每一种可能的功能纽合以及软件的功級性_你 
我皆九人，有时候，很容易就漏掉一两个特殊的状况， 
有了使用类中4■个单独功能性片段的測试，你 T 以螭 认亊 
情在任何场景中都有效.即使你不特别《试该场景.碥认 
4■一个小片段有效是让你相 s 安全地 m 设这*小片段的《 
合也会有敫的方式， 
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测试案例看起来像什么 

测试案例 (test case ) 对所测试类里的毎一个功能性片段郎冇测试 
方法 （test method ) , W 此，对于像 DogDoor 这样的类，我们会测 
试打开狗门.关闭狗门. JUnil 会产生测试类， 看起来躭*这样： 


imewock.TestCase; 




public class RemoteTest extends TestCa 
I 

public void testOpenDoor < - 

枝爱 DogDoor door = new DogDoor (); 


3 dog door by using the 
• T*s«C«se47Um'! 的卷 


OojOemS^® 


—个功被 



Thread. currentThreadO. sleep (6000); 
)catch (InterruptedCxcepCion e) 1 
fail ("interrupted thread®); 

J 

> assertFalseldoor.is 


—个 谢技方 


杜右: •在*该拘兵闭. 
不4去 i ® 用 (( o<n . clot *(). 

印不4 掏 (1(|*破馑用 
的方式。 


在锖瑰 ( context ) 里测试你的软件 

注意.不是直接测试 DogDoor 的 open() 与 cloa*(> 方法，此 SI 试使 
用 Itomot •类（狗门在真实世界里运作的方式）。这确保此测试模拟 
真实的使用状况，即使它们一次只测试单一的功能性片段 • 


相冋的亊情发生 fttMtClowDoorO 中，代 替调用 C 1 OM 0 方法，该 
测试以 遥控器开门，等待一段特定的时间后让狗门自动关闭，接》 
再测试-下，有看狗门是否关闭。这是狗门将被使用的方式，因此 
应该被 M 试， 
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邛.编码标准鸟玎读的程 序代码 

阅渎源代码应该很«阅读书籍，你应该能够看懂正在发生什么亊， 
即使《到一些问题，只要继续谈下去，想出这些问题的答粜应该也 
不难 • 好的开发者与设计者应该 愿意花 一点额外的时间去编写具有 
可读性的程序代码，因为这提升了维护与®用程序代码的能力。 

下面的例子是第 2 章与第 3 章所写的 DogDoor 类的较具可读性的版本， 
内含详细的 注释， 
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体大软件不 R 是玎运作的程序代码 

许多开发者会告诉你 编码标 准与格式化是一件令人痛苦的亊，但是 
你不花任何时间来 It 程序代码凡冇可读性时会发生什 么事： 


public class DogDoor 
( 

private int noc ■ 0; 
boolean dio = false; 


ij I $ i- ；4 <5 '•* • 


沒布瑰明这螫耷 * s 

…… 





ii 眘方沾也 4 . 
名钤宠全不* 椹 这找。 


public void run() 1 
if (--noc -- 0) dio - false; 冬 ■、^ 


珅埘釦问 R | 让 


纯粹从功能的角度来看，这个版本的 DogDoor 与上一 M 的版本完全 
一样，然而你现在应该知道伟大软件不只是可运作的程序代码，而 
是可维护.能重用的程序代码。大部分的开发者不会想维护这个版 
本的 DogDoor, 弄清楚它在做什么或者哪里可能出错可是一件痛苦 
的事。想象一下，如果有10,000行的程序代码都这样，会不会让你 
流彝血？ 


编©兵有可诿惟的移戽代碚， it 移辟比软耔维 
铲及重芹，对你与丼他扞矣考都—样„ 
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重构 

*10. 重构 

重构 （refactoring) 是«改程序结构但不 tt 改其行为的过程. ® 构是为了增进 
程序代码的消晰度、灵活性及可扩展性而做，通常与设 U •中的特定改裨有关， 
大部分的重构都 ft 相当简申.的，并且将热点放在 程序代 码的特定设计方面， 
例如: 


重构玖变栈 疼代碚 
的户梆鍩柃，??> 
影响移 序代碚的行 
为。 

尽管这段程序代码没什么特別的错误，但没有它应该有的可维护性。 get - 
DiaabilityAmountO 方法实际上做两 件寧： 检査是否符合失能 
( disability ) 的资格 ( eligibility ) ,接着计算失能的程度 (disability amount ). 

现在.你应泫知道这违反 SRP (单一职贵原則）。事实上，我们应该把处理资 
格要求 (eligibility requirements) 的程序代码与计算失能程度的程序代码分开 
来，因此.我们可以将这段程序 代码® 构成 这样： 

public double getDisabi1iCyAmountI) 

// Check for eligibility 

il (iaEligiblePorDisabilityO)( 


return 0; 


现在，假如失能的资格要求改变，那么只有 isEligibleForDisabilityO 
方法需要改变，而负责计算失能程度的方法不变， 





将重构视为程序代码的体检。它应该是一个持续不断的过程，因为单独留下 
的程序代码《向 T •越来越难重用。回到现有的程序代码，利用所学的新技术 
为它进行*构，那呼必须维护与 ffi 用你的程序代码的程序员会感谢你的。 
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附录 2: 欢迕光临对象村 



准备去旅游卩巴。 是拜访对象村的时候了，在那片土地上，对象正 
在做它们应该做的事，应用程序全都是封装良好的（不久，你便会发 
现它的真正意思），设计則易于重用及扩展。然而，出发之前，有些 
事情得先让你知道，有些语言技术你必须先学习》不过别担心，用不 
了多久你便会理解，你将会说 oo 的语言，就像你已经在对象村的设 
计 ft 好区域 (well-designed area) 里生活了许多年， 



为你准备的 oo 随身包 

欢迕光临对象村 

不论这垃你 第一次 来到对象村，还是以前躭来过.这里永远 
是一个独 -- 无二的 地方， 然而琳情在这里有些不同，在你深 
入本书的主要部分以前，我们在此帮你培养一点方向感。 



本中的》 


；2相》本劣中 S 尊 《 
的《4 代坏坧 婀,. 


-S 我们》蠡5 «承. 
我们也 食垠祛 地赛卷 
多& 。 




个碑的< 


6义«- 
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UMU 类珍 

在这本书里，我们将谈论很多的类与 对象。 然而，要想肴 e 200行 
程序代码的 m 时乂能将焦点放在整体轮廊上，这是相当不容 s 的. 
因此,我们会利用 UML (Unified Modeling Language. 统 -it 模语 
言）。该语 if 被坩 來将程序代码与应用程序结构的必®细节（没有 
+耑要的 细节） 传给其他开发者与客户。 


S 5： i 的方式.“祕让巧 ■ 
豪5： 6用技存中炎的一的 * 
式。 


类田的 


这费4 SI 妗由*交_蓍 

(».m6«« ®7 _Ns ^l 

个和州 .. …* 4 
它的 t* ( 1 ««) 


ri 


C ^[ rplane ^)< 


speed: int 


I getSpeed(): int 
setSpeed(int) 


Hr ” 




s 変蓍岛/ 或古法 - 


^ iM 尖你的铝笔 

为 Airplane 类编写构架。 

使用上述类图，看看你是否能为 Airplane 类编写构架。有没有发现 
这个类围漏掉了什么？将那呰遗 漏的笱 在下®的空白处. 




4 尖 你的铝 f 


为 Airplane 类编写构架。 


利用第577页上的类 ffl . 你应该可以为 Airplane »编"*.】堪本的 
构架。这里是我们所 做的： 


<食 ft ® 典來* 诂 
致们& S 

r Mic - 

—OW* pwMCl"。 


* K x - . * @ ft 赛货 

下.的子涑 
s 的沟 a 皋 s . ii # 
«CJ* — 


public class Airplane 
private int speed; 

public Airplane () 

) 

public void setSpe 


public int getSpeedO 
return speed; 



cf^rJttsis 

S 了戏受始 <2 的构 .年也 


zitsmfji …… a<n* 

5 普 《 iS . f 5 e ： is *4«4 




问： 


那么.类明不是类的非常完 


设计 • 道过使用像 UML 这样的 标准， 
我们全部说着 相用的诺言. 确定用我 
们的田形诙论相 n 的亨。 


1®1 : 听起来好像在 筒单的 类围上 

还 有一些 东西。 


^: 是的，不过它本来就不打算 

那 么做。 类 a 只是一种传入类的变量 
与方法的基本节的方式，让讨论《 
序代玛变得容 ft , 而不会强迫你 t 力 
地看上百行的 Java . C 或 Perl 的程序 
代码. 


I ®): 那到底是谁想出 UML 这玩意 
儿？ 

^ : UML 规范在 Grady Booch . 

I var Jacobson 与 Jim Rumbaugh 
(三个 真的很 聪明的家伙） 这三人 • 


^ : 亨实上，类田只是 UML 的 

一小部分， UML 还有各种 S 形，用来 
表示对象的状态，表示应用程 序的亨 
件*序.甚至表示客户的需求以及与 
系统的交互.关 于类田也还有 许多其 
他东西要学. 


I ®): 我有自己的方法绘制类田. 
不行吗？ 

^: 拥有你 ft 己的表示法没什么 

不对，<8是会让其他人 很堆理 解你的 


的领导下，由 Rational Sof 丨 ware 开 
犮出表.后来便交由 OMG 
(Object Management Group ) 管9 • 


然而，在此«,你只需要 *577 页上 
的基■础知识.«后在本 书有需 要的地 
方，还会诙到能 I 示在类图里的其他 
东西以及其他类*的田形. 
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狻 f 来是： 继承 

继承 < inhcrii ance > 坫对象村*础的编程 主埋之 -。•个类继承 
来自另一个类的行为 （ behavior ) ,黹要的话，也可以改变该行 
为，来继承如何在 Java 中运作，其他语言也与这 相似： 


: m 


public, class Jet extends Airplane ( 


private static final int MULTIPLIER ; 


基_个典躁的关霣 P v 

字. 

的** : © it . a 会 if 
用 ^•'VUnt (Jtt 的 ii 类） 

的构 it *® 


t sM 用。 




public void seCSpeed(int speed) { 
super.setSpeed(speed * MULTIPLIER); 

1 ^__ 寻 si 橐的 H 於（也 

.,..., ~~~ 叫卵 . 这 ㈣ 

public void accelerate” { 

super.setSpeed(g etSpeedO * 2); ?JL ( 




哚 5* 奏 tliiit 的方 
■t. 孑 S 也芍 以坩知 ti 


Ut 也从 Aii)>i<me <4 承 f etS r eedOi it, © 
jf) ) et fS 用島 和 (9 的放本.斯以 
我们不*鹐英《何《4代运来戋4这个* 
：t sp 值伪 i4 奄在 f 寿也铯的 
gfetft f 拥用它 


"" 仿芍 W if 用 . fttSpeedO 
用州 x 就 


继承让你基于其他类来构建 
避免重复及反复 H 见的程 序代病 -。 





游泳池畔的好时光 



你的任务垃从下面的游泳池里捞出 
裎序代码片段，并将它们放 S 于 
L 右边的程序代码的空格里。 

相同的程序代码片段可 
以使用-次以上，不 
需要用到所有的程序 
代码片段。你的目标 
是创违一个可编译、运行、 
产生下列输出的类。 
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还有多0 


多态 （ polymorphism ) 与继承*密相关。当一个类继承另 
—个类时，多态 ih 子类能代替父类。 



困 rt . ft 在这.你9 
以<5 sift …… 



% 

| P ) :多态有什么用处_? 



Airplane plane = new Airplane 0; 

Airplane plane = new Jetn ： 故装 Rocfc«t4A“jiU”e 

Airplane plane = new Rocket(): 的另一个 子类， 


1^1 : 我还是不明白多态怎么让我的程序代码比较灵 


^ : 你 T 以編写使用父类 (^ Airplane ) 的 C 
序代玛. 1* 实味上将使用任何* fi 的子类（像 J « t 或 
Rocket ). 因此.你的《序代码是比较灵活的. 


活？ 


^ : 饥如需要新的功能你 T 以編耳新的 

Airpl « n ■子类。但是，囚为你的《序代鵠使用父类•所 


以《序代鷂的其余部分无需做任何改 t . 新的子矣就 T 以 








最后侄不是 最不重要的： 封装 


封装 （cncapsulaiicm) 是将部分数据对炖用程汴的其余部分 tt 藏起 
来.汴11限制程序代码 )t •余部分访问该数据的能力（译注1> •假 
设我们*写 Airpl.n* 类如下： 

public class Airplane { 


我们 it*”"” 
ipublic. * 不 & 

枝咚 的的 < 5 舴分 


public int speed; 

public AirplaneO { 

l 

public void setSpeed(int speed) 
this.speed = speed; 

) 

public int getSpeedO < 
return speed; 


规在，任何人都 sftvCI 捿设定 speed 

这样的改变表示应用程 (T •的其他部分不再耑要调 》U«ts P ««<JO 來设 
定飞机的速度， 《 pe«d 变里可以被蓖接设定，所以这段程序代码会 
编译 成功： 


封麥保铲栈存 
代碚里的倌息免 
子衹 > iE 确地 


public class FlyTest2 { 

public static void main {String [] args) 
Airplane biplane = new AirplaneO; 

biplane, speed = 212; 





不必再僅用鸟 
s«Sp«〆）. 戧们 


►译注1:本令的 fl 站上讨论到这段文字 T 用史严谨的方式釵述.放在这X供读者 参考： "对装*将类 
的实现1»藏 起未. 好让它*易使用与改 t. 対装让类以黑龛 (black box) 的方式提供服务 
给它的用户.忸不开放该《序代玛让其他人改 t 或者以《*的方式使 用它。 封装是邊《开 
H1*W (OCP) 的关镱技 术，" 
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有什么大不了的吗？ 

好像没什么大问 H, 不是吗？然而，如果你创嬝丫 j«t 并 a 像这样 
设定其 speed, 会发生什么事？ 


值用 J«t_ H 
值用麯涑。 


public class FlyTest3 ) 

public static void main<SCring[] args) 
f" Jet jetl = new JetQ; 

-* K jetl.speed* = 212 ;~~~~ - — —- 

C System.out.println(jetl.speed); 


C Jet jet2 = new Jet{); 

值用扣 e . 僅 jet2.setSpeed(212); 

用 射装。 (. System, out.print ln(jet2. get Speed ()); 、 

» 


嫌承 

辦以伢楚用來 tii 
* 的 sp ,. d 変螯 . 秕俅达 
4 的_邾分。 


祕值用 84 我们 
用 扶问邛 《以 




尖你 的箝笔 


封装数据的价值是什么？ 

输人、编译并运行如上所示的 FlyTest3_java 的程序代码后，你的输 
出看起来像什么？在下面两行空格里将运行结果写 出来： 

jetl 的 speed : - 

jet2 的 speed： 

你认为这里发生了什么亊？写下你为毎一个 Jet 实例决定速度值的理 

由;_ 


最后，总结你认为的封装的价 tft 是什么： 



4 尖你的铝 I 
解答 


封装数据的价值是什么？ 

输人，编 if 并运行如 Ji 所示的 FlyTest3.jav a 的程序代码后，你的输 
出右起来像什么？在卜_面两行空格里将运行钴果驾 出来： 

jetl 的 speed： __ 

jet2 的 speed : -- 


你认为这里发生了什到亊？写下你为每一个 Jet 实例决定速度值的理 
由： 


/ 

的 speed 之箾将 法值桑 X 2„ 然而， 

S 我们£摟手动设 

你的釜*7•必课我 

定 speed 変鱟时，則澶 «将它*认2。 


们的； tt 一样. 

最后，总结你认为封装的价值是 什么： 



封 Xff 扩数榫 兔子*不 

f « 两封装 W 数掩. 


* 对数埔所®的 ff 何 it * 成检金 IPfiSO 保护， ® 为数提 


不能拈 taa 闷。 



W 么.敵的不 s & i ® 8 
藏.它也4係你 來氓*霣对 
的方法 AiA 用《! 


仿言的和关这 
料: 式定义.考试 
-吋， , 





m : 将譌枝无棄 (ptoftamminf elements) ft 含存较大、较抽 
象的定 f 本内 的过 VI, 也破坊碎信想 ® (Motmation hidinf) ^ ^ 
兵 i • 主点分處 （ sepamtio” o< co”ce»”s ) 。 
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、脅问和 匈埋 


I®): 那么.封装完全与让你的 

所有变■成为 private 有关吗？ 

: 不.封装是关系到将信息 

与不该弄乱该信息的应用其他 
部分分开的。使用成 B 变量，而不 
想让应用程序的其他部分直接操控 
你的数 《. 郢么就通过让数据变成 
private 来将它分离开来。极如数据需 
要被*新，你 T 以提供方法来专职处 
«该数 据. 就诹我们在 Airplan •类 
中所 做的： 使用 g _ tSp «« d (> 与 
setSpeedO 

I ®): 除了变置之外.还有其他 

方式使用封装吗？ 

^: 当然有.事实上，在第 

■章. 我们会看到如何将一纽特性从 
对象中封装出来，确保该对象不会不 
正确地使用坏姿特性。即使我们要处 
理一整纽特性，仍然只是将一 fe 信息 


I ®): 那么.封装真的是关系到 

数据的保护.对吗？ 

^: 事实上.它甚至不仅如 

此！封装也 T 以将行为从应用《序的 
其他部分分开。因此.你可轮在一个 
方法里放了许多《序代码并 i 将该方 
法放到类中.你已经将行*与应用《 
序的其他却分分开.而应用 任序必 《 
使用你的新类与方法.才能访问该行 
为.«而这与 ft* 的处理*則相 Ph 
将应用<1序的一却分分离出来.保妒 
它们免于被不正螭地使用. 

(®1 : 哇. 我不* 定我*否全部 
理解这一切.我*要做什么？ 

^ : 只要*读往下读.确认你 
理解第 584S 上的习趕解答，你便为 
第1幸作好准各了.我 们将花 费很多 
时间在这400原 W 与椒•念上，所以 
此刻不要觉得你需要完全理解每一忤 


封黎将势据与应芹 
栈序的行 为尹离 扞 
弗。 

子是，侪可％掌拉 
每—个梆穸扣何衹 
应芹栈/?的其他梆 
尹僙芹。 
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OOAfeD 填字游欢 

花点时间回颐•下本琪所提的槪念，准 备好以 稳定的步伐迈 
向分析，设计 . oo 编程以及伟大软件的世界。 



横排提示 

3. This 15 when a subclass can substitute for 
its superclass. 

4. Class diagrams don't show details about this 
port of our class. 

5. A class that inherits from another class is 



6. Encapsulation lets you do this to 
information. 

7. A class that is inherited from is called this. 


竖排提示 

1. Another term for encapsulation is separation 
of this. 

2. Polymorphism helps make your code 





游泳池拼田游戏解答 


游奂泜拼留游戏 
斛著 

你的任务是从下面的游泳池里捞出 
程序代码片段，并将它们放罝于右 
边的程序代码的空格里。相同的程 
序代码片段可以使用一次以上，不 
耑要用到所有的程序代码片段。你 
的目标是创 a —个可编译，运行. 
产生下列输出的类. 


输出： 



public class FlyTest { 

public static void main(String[] args) { 
Airplane biplane = new Airplane0; 
biplane. setSpeed (212); 

System.out.printl n (biplane.getSpeedOl ； 

Jet boeing = new Jet(); 
boeing. setSpeed (422) ; 

System.out. println (boeing.getSpeedOl ; 

int x = 0; 
while (x<4)) 

boeing.accelerate()； 

System. out. println (boeing.getSpeedOl •' 
if lboeing.getSpeed() > 5000)( 
biplane.setSpeed(biplane.getSpeedO * 2>; 

1 else { 

boeing.accelerate()； 

x**; 

System .out .print l n (biplane.getSpeedOl ■' 
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